This essay is about a specific architectural decision and why we believe it changes the SaaS-vendor / customer relationship in a way the industry needs more of. The decision: every customer gets their own database. Not a row with a tenant_id column. Not a schema. A real, separate Postgres database with their own credentials, their own backups, and a one-button download.
This is unusual for a SaaS targeting shops of 1-20 people. Most multi-tenant SaaS at our price point uses shared schemas with row-level security. It's cheaper to operate. It scales more linearly. The economics push hard in that direction.
We chose differently, deliberately. Here's why.
The standard pattern, and what it costs the customer
The dominant multi-tenancy pattern in modern SaaS is shared-everything: one database, one schema, every tenant's rows mixed together with a tenant_id column on each row. Application-level filtering keeps tenants from seeing each other's data. Sometimes row-level security policies enforce it at the database layer.
This works. It's also the model behind every major horror story you've read about SaaS data leaks. It produces predictable failure modes:
- Cross-tenant query bugs. Forget a
WHERE tenant_id = ?clause in one query and you're looking at every customer's data. - Backup recovery is all-or-nothing. If you need to restore one customer's accidentally-deleted record from yesterday, you're either restoring everyone's or doing surgical export/import gymnastics.
- Performance contention. One customer running a heavy report can slow down everyone. Indexing strategies have to be designed around the worst-case tenant.
- Compliance asymmetries. If one customer needs a stricter audit trail than another, you build it for everyone or nobody.
- Data export is awkward. The platform "export your data" feature usually produces a CSV dump with no schema. Re-importing it elsewhere is a multi-week engineering project.
For SaaS at scale (millions of users, freemium models), the operational economics still favor the shared-everything pattern. The trade-offs are real but tolerable.
For SaaS targeting businesses who depend on the data inside — shops of 5, 10, 20 people running their bookkeeping, their CRM, their operations — the math changes.
What per-tenant databases actually mean
In Ledger247, when a new customer signs up, we provision a separate Postgres database for them. Not just a schema. A real database, with its own credentials, its own connection string, its own backup schedule.
The customer can request, at any time, a pg_dump of their entire database. Schema, data, the whole thing. They get a single SQL file they can restore into any Postgres instance anywhere — their laptop, AWS, Azure, on-prem.
The architectural cost is that we operate ~thousands of databases instead of one. Operationally, that's harder. Cheaper-by-the-row, it's not. We compensate with infrastructure that's been designed for this pattern from day one: shared connection pooling at the application layer, automated backup and migration tooling, monitoring that aggregates across tenants without losing the per-tenant view.
The customer-facing benefits compound:
Real isolation, not enforced isolation
A bug in our application code can't accidentally surface another customer's data, because the connection string is tenant-scoped at the network layer. There's no shared table to mis-filter. The isolation isn't a discipline we have to maintain — it's the architecture.
Surgical backup and restore
If a customer accidentally deletes a quarter of invoices and asks us for a point-in-time restore, we restore their database to the previous day. Nobody else's environment touches the operation. No coordination overhead.
Compliance that respects the customer
Some customers need data residency in Canada Central. Some need stricter audit logging. Some want full backup-encryption-at-rest with their own KMS keys. Per-tenant database lets us meet each requirement without forcing every other customer onto the most-stringent setting.
Departures that don't poison the well
The most important benefit, and the hardest to articulate honestly: customers can leave us cleanly. They request pg_dump, they get a portable export, they restore it elsewhere, they're gone. No support tickets. No "we'll review the request." No multi-week migration project. No data hostage situation.
Most SaaS vendors fight to prevent customer departure. We don't. The architecture says we shouldn't be able to.
Why this is good for the customer relationship
The thing that surprised us is that customers who notice the architecture stay longer, not shorter. The right to leave seems to make them less interested in exercising it.
The dynamic isn't unique to SaaS. Trust-based relationships in any domain work this way. The professional you trust to give you honest advice is the one whose advice you keep coming back for. The vendor who lets you leave is the one you don't want to.
The right to leave is what makes the choice to stay meaningful. Lock-in is the absence of choice; the absence of choice corrodes the relationship.
Our retention numbers are what they are. The cost of operating per-tenant databases is real. The math works.
How this principle generalizes beyond Ledger247
The "per-tenant, downloadable, no lock-in" principle extends to how we deliver Stage 03 (Systems) consulting engagements:
Power BI environments live in the customer's tenant
When we build a Power BI environment for a client, it lives in their Microsoft tenant, on their Power BI Premium / Fabric capacity. We're admins by invitation; we lose access on departure. The semantic models, the reports, the workspace structure — it's all theirs. They can fire us tomorrow and the entire BI environment keeps running, because it's in their infrastructure.
Compare to consultancies that stand up "our" environment and "give the customer access." That model is lock-in by architecture. The customer never controls the underlying assets.
Custom apps ship with full source code
When we build custom Power Apps, React/Node web apps, or AI-agent integrations, the customer gets a Git repository on their own GitHub/GitLab/Azure DevOps. Not "our repo with you as a collaborator." Their repo. They own the source. They own the deployment infrastructure. We helped build it; they own it.
CRM and ERP rollouts are configured in customer tenants
HubSpot, Dynamics 365, NetSuite — configured in the customer's account, billed to the customer, owned by the customer. We're a guest, not a host. The customer's relationship with the platform vendor is direct, not mediated through us.
Data exports are first-class
Every system we ship includes a documented export path. How to dump the database. How to export Power BI semantic models as .bim files. How to bulk-export CRM contacts. The first time a customer needs to export, the path is documented; nobody is figuring it out under pressure.
The objection that comes up most often
"This sounds great in principle. Doesn't it cost more?"
Yes. Operating per-tenant infrastructure has a cost overhead vs shared-everything. We've measured it; for our shape, it's roughly 30-50% higher infrastructure cost per customer than a shared model would be.
That cost shows up in our pricing. Ledger247 isn't the cheapest bookkeeping SaaS — it can't be, because the architecture is heavier. The customers who pick us know what they're paying for: the right to leave, the right to own their data, the right to compliance that respects their reality.
For consultancy engagements, the principle is roughly free — because we're working in the customer's tenant anyway, the architecture follows naturally. The cost is mostly behavioral: we have to actively resist the engineering instinct to build something "for them" that lives in our infrastructure. The discipline is harder than the engineering.
The summary, in one paragraph
Per-tenant data ownership isn't paranoia. It's an architectural decision that aligns vendor incentives with customer outcomes. It costs more to operate. It makes the customer relationship better, because the relationship is built on choice rather than friction. And it shapes the kind of customers who pick you: ones who care about owning what they're paying for, who want vendors they can trust with their data, who reward the consultancy or platform that takes that trust seriously.
If you're a SaaS founder evaluating multi-tenancy patterns, the easy answer is shared-everything. The right answer depends on what kind of business you want to build. If you want to build something where your customers depend on you because you've earned it — not because they can't leave — build per-tenant. Pay the operational cost. Make the architecture say what your marketing claims.