Database-per-tenant gives you hard isolation at the cost of connection management complexity.
Why we chose database-per-tenant and how it plays out in practice.
Tengai POS uses a database-per-tenant multi-tenancy model in MongoDB. A master database holds organizations, users, and subscription data. When an organization onboards, it gets its own database for sales transactions, terminals, shifts, inventory, and VAT5 certificates.
For a tax-compliance system, data isolation isn't optional — it's a regulatory expectation. A query bug or misconfigured filter in a shared-collection model could leak one business's financial data to another. With database-per-tenant, that entire class of bug is eliminated at the infrastructure level.
It also makes per-org operations trivial: backup one org, migrate one org, delete one org — all without touching anyone else's data.
The main cost is connection management. Each org database needs its own Mongoose connection, and those connections need to be cached and reused rather than opened fresh on every request. We use a connection registry pattern — look up the org's connection from cache, create it if missing, and pass it through middleware so service functions always operate on the right database.
Cross-org queries (like the ops admin dashboard showing aggregate stats) require explicit fan-out across databases. This is fine for admin views but rules out naive joins or aggregations across tenants.
The pattern has held up well through development and testing. The isolation guarantee simplifies reasoning about data access — every service function knows it's operating within a single org's boundary. And the connection cache keeps the overhead manageable even with dozens of active organizations.