Every cloud ERP has to answer one question: how is your data kept apart from every other customer's? There are two broad answers. In a multi-tenant system, customers share the same application and usually the same database, and the software keeps each customer's records separate. In a single-tenant system, each customer gets its own copy of the application, its own database, or both. The choice shapes your cost, how quickly you get improvements, and what you should ask about security.
Why it matters for a distributor
An ERP holds the most sensitive data a distributor has: what each customer pays, your margins, supplier costs, lot tracking records and the general ledger. A competitor seeing your price list is a commercial problem. Losing lot records in the middle of a recall is a regulatory one. It is worth knowing how the walls are built.
How multi-tenant works
One application serves every customer. Each record carries a tag that says which customer (tenant) it belongs to, and the software applies that filter to every read and write, so you only ever see your own rows. The servers, the database and the engineering team are shared, which spreads the cost.
The risk to understand is a software mistake: a query that forgets the tenant filter. Good vendors guard against it at more than one level, for example by applying the filter automatically rather than relying on each developer to remember it, and by running tests that try to read across tenants and must fail.
How single-tenant works
Each customer gets its own database, and sometimes its own servers and network too. A mistake in one customer's query cannot return another customer's rows, because those rows are not in that database. That is a stronger wall, and you pay for it: dedicated infrastructure costs more to run, and someone has to upgrade and monitor every copy.
The variations in between
| Setup | What is shared | What is separate |
|---|---|---|
| Shared database, tenant tag on every row | Application, database, servers | Only the rows, by filter |
| Separate schema per tenant | Application, database server | Your tables |
| Separate database per tenant | Application, often the servers | Your whole database |
| Fully dedicated | Only the vendor's team | Application, database and servers |
Vendors often mix these. Ask which one applies to your account, not only which ones the vendor offers.
Upgrades and new features
This is the difference you notice day to day. In a multi-tenant system everyone runs the same version, so an improvement or a fix reaches every customer at once. In a single-tenant system each copy can be upgraded on its own schedule. That gives you control over timing, but copies tend to fall behind, and a fix you need may wait for your next upgrade window. If you choose single-tenant, ask how upgrades are scheduled and who pays for them.
Performance
In a shared system, one customer running a very heavy report could in theory slow others down. Vendors manage this with limits and capacity planning. Single-tenant removes the neighbour, but not the need for enough capacity on your own copy. In both cases, ask how the system performs at your busiest hour, with your order volume, not an average.
Backups, restores and leaving
- Backups. Either model should back up your data off-site and test that restores work.
- Restoring only your data. In a shared database, rolling one customer back to yesterday is harder than restoring a dedicated database. Ask how the vendor would recover your records alone if you needed it.
- Export. In either model, you should be able to get your data out in a usable format, by export or through an API. Our piece on API-first ERP covers what to look for.
Security: what to ask
Single-tenant gives a stronger wall between customers, but that wall is not where most trouble starts. Stolen passwords, accounts that should have been closed, and people with more access than their job needs cause far more problems. A dedicated database does not help if the vendor's wider security is careless. Ask any vendor:
- How is tenant separation enforced, and how is it tested?
- Who on your team can see our data, and is that access logged?
- What sign-in protections do our users get?
- Can we control what each role sees inside our own account?
- Is our data encrypted in transit and at rest?
- How do we get all of our data out if we leave?
When single-tenant makes sense
- A contract or regulation that requires your data on dedicated infrastructure, or in a specific place.
- A certification you must hold that the vendor's shared setup cannot support.
- Heavy custom code that would not run in the shared product. That is often a sign the product is a poor fit.
For most food distributors, none of these apply. Multi-tenant usually costs less and keeps you on the current version, and with a vendor that enforces and tests separation properly, it is a sound choice. If you are still weighing cloud against your own servers, see cloud vs on-premise ERP.
The wall inside your own company
Whatever the architecture, the wall you deal with every day is the one inside your company: who sees margins, who can change prices, who can void an invoice. In APFoodz you decide what each role can see and do, and which actions need an approval (see roles and permissions).