I am planning to create a new collection for every user in my app to ensure complete isolation. My coworker says this is a bad idea, but why? Is there a hard limit or just a performance limit to how many collections MongoDB can handle? I want to make sure I don't paint myself into a corner.
MongoDB does not have a strict hard limit on collection count, but creating a collection per user introduces severe performance degradation due to metadata overhead, index management constraints, and inefficient resource utilization.
3 answers
Don't do it, unless you want to spend your weekends debugging memory exhaustion and slow query planning.
MongoDB maintains metadata for each collection in the catalog, and once that cache grows too large, the database performance tanks regardless of how much hardware you throw at it. Your coworker is right to be concerned because this is an anti-pattern that ignores how the underlying engine handles namespaces and index tree management.
While MongoDB technically permits a large number of collections, creating one per user is fundamentally contrary to architectural best practices. From a testability and maintenance perspective, you are introducing significant overhead that will cripple your ability to manage schema migrations or index updates effectively.
Consider this a cautionary tale from a project I audited years ago where a team attempted a similar multi-tenant isolation strategy. They quickly discovered that standard maintenance operations, such as running a collection-wide scan or validating data integrity, became impossible because every administrative task had to be iterated across thousands of distinct collections. The system eventually hit severe performance bottlenecks during indexing, as the background processes competed for system resources to catalog the sheer volume of separate entities.
You should reconsider your data modeling strategy because the per-user collection approach introduces severe operational friction.
- Individual collections increase the size of the catalog which slows down metadata operations
- Managing index creation and schema updates becomes a logistical nightmare as your user base grows
- Resource contention during background processes will cause unpredictable spikes in latency
- Backup and restore workflows become increasingly complex when distributed across thousands of distinct files
