Why every tenant on our platforms gets its own database

It's common for multi-tenant SaaS platforms to store every customer's data in the same tables, separated only by a tenant_id column and a WHERE clause. It's simpler to build, and for a lot of products it's a reasonable trade-off.

We chose differently for Adcoar Tours and Adcoar Reach: every tour operator, every organisation sending messages through Reach, gets its own isolated database. It costs more upfront — more provisioning logic, more moving parts to manage — but it buys three things we think matter more for the businesses we serve:

• No cross-tenant query bugs. A missing WHERE tenant_id = ? in a shared-table system is a data leak waiting to happen. In an isolated-database system, that entire category of bug is architecturally impossible.
• Independent scaling. One operator's booking rush during peak season doesn't slow down anyone else's dashboard.
• Clean data ownership. When an operator asks for an export of everything they own, or asks us to delete it, the answer is a single, complete database — not a query across shared tables hoping nothing was missed.

None of this is unique or clever — it's a well-known pattern. But it's the kind of decision that's invisible when it's working and very visible when it isn't, and we'd rather it stay invisible.