Every customer gets their own database
Many vendors put all customers into one shared database and separate them with a column:
customer_id = 42. That is convenient to operate — and it means a single forgotten filter in a
single query is enough to serve customer 42's data to customer 43.
We go the other way: every company gets its own database when they order. Not its own schema, not its own row — its own database.
Classic SaaS puts every customer in one table. Your rows sit next to strangers'.
Why this isn't a detail for engineers
The difference sounds architectural and is in fact a statement about what can happen at worst.
| Shared database | One database per customer | |
|---|---|---|
| Separation | One column: customer_id = 42. | A database of its own. No foreign data sits in it. |
| One forgotten filter | Shows other customers' data. | Shows nothing — there is nothing foreign to show. |
| Data export | A subset of someone else's set, has to be filtered out. | A self-contained set, handed over whole. |
| Self-hosting | Not provided for. | Same software, same database, different place. |
| The price for it | Cheaper to operate — for the vendor. | Migrations have to run across many databases. That cost sits with us. |
In a shared database, separation is a rule that has to be honoured on every single query. With a thousand queries in the code, it has to be right a thousand times. With separate databases, separation is a property of the connection: the query cannot look elsewhere, because nothing else is there.
That is why we consider the extra work worth it. Not because vendors with a shared database are careless — most are not. But because the safety claim there is "we're careful" and here it is "there is nothing to be careful about".
What it means in practice
- A bug cannot show someone else's data. There is no foreign data in the database it runs against.
- Moving out is possible. Your data exists as a self-contained set, not as a subset of someone else's. That is the precondition for "take your data with you" being more than a promise.
- Self-hosting stays an option. If regulation requires you to host in-house, you can — it's the same software on the same database, just somewhere else.
- A restore concerns you only. If you need yesterday's state, your database is rolled back. In a shared set, that is the single most awkward request there is — you cannot roll one customer back without touching the others.
- Other people's load stays out of it. A customer running a heavy report doesn't slow down your data entry.
What it costs you
Nothing in effort. Provisioning runs automatically: you order your modules, and in the background an instance appears that belongs to you alone — including permissions, master data and the documentation for exactly the modules you booked.
- 01
Order
Area, modules, hosting route. After that it is settled what gets built.
- 02
A database of its own
Not a schema, not a row — a database that belongs to you only.
- 03
Modules move in
Every booked module brings its own tables, permissions and master data.
- 04
Permissions and access
Roles are in place before the first person signs in.
- 05
Updates
Migrations run across all separate databases — that cost sits with us.
- 06
Moving out
A self-contained set, handed over whole. No filtering required.
The price sits with us, not with you: we have to build migrations so they run reliably across many separate databases. That is more work than maintaining one large schema — and a different kind of work:
| Shared database | One database per customer | |
|---|---|---|
| Shipping an update | Once, effective everywhere | Across every instance, each has to run through |
| A failed migration | Hits everyone at the same time | Hits one instance, the others keep running |
| A customer on a special state | Hard — everyone shares one schema | Possible without touching anyone else |
| Effort for the vendor | Low | High, permanently |
| Effort for the customer | None | None |
The last row is the point. The decision moves work from the customer to the vendor — which is exactly why it is rarely taken.
Where that database sits
Location is a second, independent question. Separate databases can run in Germany, in the EU, or in your own building. We offer all three routes; the hosting options are here.
The order of the arguments matters: "servers in Germany" answers the question of place. It does not answer the question of separation — both designs can sit in the same city. What follows from that for permissions, deletion and record-keeping is in the piece on getting your data out of an old system.
And if you ever want to leave: the data is there, whole, without anyone having to filter it out of somebody else's set first.
- Engineering
- Privacy