Why I Think Small-Business ERP Should Give Every Tenant Their Own Database

<p>If you read enough SaaS architecture advice, you'll see the same default again and again: one big database, a tenant_id column on every table, and a filter on every query. It's cheap and simple to run, and for lots of products it's the right call. For the kind of software I build I think it's the wrong default. My view is that a small-business ERP should give each tenant its own database.</p><p>This isn't a new or exotic idea. It's one of the standard multi-tenancy patterns, and it's how I approach multi-tenant ERP design. Here's why it suits this kind of product.</p><p><strong>An ERP isn't a to-do app.</strong> AIREP covers the core of how a small business runs: quoting, procurement, invoicing and inventory. That data is the business. If a to-do app leaks one customer's list to another, it's embarrassing. If an ERP shows one company's supplier pricing or invoice history to a competitor, that's a breach of trust the product probably won't survive. In a shared schema, isolation depends on every query, every report and every background job remembering the tenant filter, every time, forever. I'd rather isolation came from the structure of the system than from discipline.</p><p>With a database per tenant, a missing WHERE clause is just a bug. It isn't a data leak. Code connected to one tenant's database can't see another tenant's rows, because those rows aren't there. I find that a much easier thing to reason about, and to explain to a business owner who asks where their data actually lives.</p><p><strong>It matches how small businesses actually differ.</strong> Australian small businesses don't all quote, buy or stock things the same way. A product that's moving from a bespoke client system to a productised SaaS has a lot of that variety baked into it. Separate databases make it more natural to migrate, back up, restore or inspect one tenant without touching anyone else. If one customer needs their data exported or restored to a point in time, that's an operation on their database, not surgery on a shared table.</p><p><strong>It lines up with values I care about.</strong> I care about people owning their data. I can't hand every customer their own server, but a clean boundary around their records is the next best thing. Saying "your data is in its own database" is a plain, honest statement. I like being able to make claims that simple without any asterisks.</p><p><strong>The costs are real, and I don't want to pretend otherwise.</strong> This pattern isn't free.</p><p>Schema migrations become a fleet problem. You aren't running one migration, you're running the same one across many databases, and you need to handle the case where some succeed and some don't. Connection management gets more involved, because the application has to route each request to the right database instead of using one pool. Cross-tenant reporting, the kind you'd want for understanding how the product is used overall, can't be a single SQL query any more. And every tenant has some baseline overhead even when they're barely using the system.</p><p>For a big consumer app with millions of tiny accounts, those costs would probably decide it, and a shared schema would win. For B2B software, where each tenant is a business with meaningful data and real consequences if it goes wrong, I think the trade is worth making. Managed Postgres, which is what I run on with Neon, takes a lot of the operational pain out of having many databases. That changes the maths compared with a few years ago, when every database could mean another box to babysit.</p><p><strong>There's an AI angle too.</strong> More and more of what I build puts AI at the centre of the workflow, not bolted on the side. When an agent is reading and acting on business data, I want the blast radius to be as small as possible by construction. An agent working inside one tenant's database can make mistakes, but it can't wander into another tenant's books. As the systems doing the querying get more autonomous, I think hard boundaries matter more, not less.</p><p>None of this means shared-schema multi-tenancy is wrong. It means the right answer depends on what's in the database and what it would cost if the walls failed. For an ERP holding everything a small business runs on, I'd rather pay the operational cost of separate databases than bet the product on never forgetting a filter.</p>