One database per company or a shared database for everyone? What it changes for blast radius, backups and leaving

In a shared ERP database every company's rows sit in the same tables and a company id filter keeps them apart. With a database per company, each company has its own database, so a query connected to one cannot read another's rows. The second design costs more to run. It makes backup, restore and exit work per company.

The two designs, side by side

In this post a company means one customer's workspace.

Neither is wrong by definition. A shared database is cheaper and simpler to update, and many products run on one with careful filters. The question for a buyer is where the protection lives and what happens on the day it fails.

What a Saudi cloud control asks for

The Saudi National Cybersecurity Authority's Cloud Cybersecurity Controls (CCC-1:2020), control 2-3-P-1-2, asks a cloud service provider to ensure separation and isolation of data, environments and information systems across its tenants, to prevent data commingling. The English text says the Arabic version is the binding one. The control does not say which design to use. A database per company is one way to give evidence for it.

Blast radius: what one mistake can reach

Take one bug: a report query that forgets the company filter.

In Tarleaks each company has its own Postgres database on a database cluster. A routing table maps the company to its database, a service connects only when that routing is active, and the cluster's connection string is stored sealed. Every table in a company's own database also carries the company id, so a business query has two protections, not one. Identity, audit, licence and routing records live in a shared platform database, separated by a company id filter, so that part is a shared design. We do not claim that a bug is impossible. We claim that the reach of a business-data bug is one company.

Backup, restore and exit

The practical difference shows up when you need your data back, or all of it out.

1. Backup. Unless the platform has switched the feature off, a company administrator can create and list the company's own database backups.
2. Download. A backup can be downloaded by a user with that permission. The download is recorded as a sensitive download of the whole company database, and the file is a Postgres dump.
3. Restore. A restore needs its own permission, the workspace name typed to confirm, and is recorded before it starts. The replaced database is kept so the restore can be undone.
4. Exit. With a database per company, leaving is a copy of one database. Ask every vendor, including us, to put the exit steps, formats and time in the contract.

A company that runs its own database on its own server is a separate case: the database must be empty and Postgres 16 or later, restore through the backup service is refused, and its backups go only to its own storage.

The trade-offs

Six questions to ask any ERP vendor

1. Where does the company filter live: in each query or in the connection?
2. What does one backup contain, and whose data is in it?
3. Who can restore, how is it confirmed, and is it recorded?
4. How do I leave, in what format, and how long does it take?
5. How does an update reach every customer database, and what happens if one fails?
6. What can a busy neighbour still affect?

How Tarleaks helps

The Security app shows the audit trail, and each company has its own database. A company administrator manages backups, downloads and restores from the settings. Read the security page for where data can live. This is evidence for your assessment, not a certification.

What to do next

• Send the six questions to your shortlist and compare the written answers.
• Ask for the exit steps in the contract, not on a call.
• Read where your data lives and the architecture post.
• Book a demo and ask us to show a backup and a restore on sample data.

Questions people ask

What is the difference between a shared database and a database per company?

In a shared database all companies' rows live in the same tables and a company id filter separates them. With a database per company each company has its own database, so a business query connected to one company's database cannot read another company's rows.

Is a shared database insecure?

Not by definition. Many products run on one and filter every query well. The difference is where the protection lives: a filter written in every query, versus the connection itself. Ask the vendor how a missed filter would be caught.

Does a database per company cost more to run?

Usually yes in operations: there are more databases to back up and every update has to be applied to each one. A vendor that does this well automates it, and the benefit is per company backup, restore and exit.

Can I take my data with me if I leave?

Ask for the answer in writing before you sign. With a database per company an export is a copy of one database. In Tarleaks a company administrator with the right permission can download the company's backups.

Does a database per company remove noisy neighbours?

Only partly. Companies on the same cluster still share its processor and disk. Caps on connections per company limit the effect, so ask what the vendor caps and monitors.

---

General information, not legal advice. The control is quoted from the Saudi National Cybersecurity Authority's English text as read on 9 November 2026; the Arabic text is the binding one. Tarleaks is not certified against it: this is evidence for your own assessment.