Single-Tenant vs Multi-Tenant CRM: Why Pooled Won
Single-tenant vs multi-tenant CRM comes down to one question: is your customer list in a database of its own, or in one shared with every other customer of the product? Nearly every CRM on the market chose shared.
The obvious objection to arguing for the other option is the right one. If keeping customers separate is safer, why does almost the entire industry share a database?
The answer is not that everyone else is careless. Shared tenancy solved a real problem very well, under constraints that were real at the time. Those constraints have changed while most of the architecture stayed where it was. If you haven't read it, start with what a shared CRM database actually looks like. This post is about the economics behind it.
Three Ways a CRM Can Hold Its Customers
Software architects describe three tenancy models. Amazon's SaaS guidance calls them pool, silo and bridge.
Pool (multi-tenant)
One application and one database for everyone. Each row carries an account identifier, and the software filters on it. This is how almost every CRM you can sign up for online works.
Silo (single-tenant)
A separate application and a separate database for each customer. The strongest separation, and historically the most expensive by a wide margin.
Bridge
A mix of the two, layer by layer. For example, a shared web front end with dedicated application logic and storage per customer. Most large systems end up here in some form.
One detail says a lot: the enterprise tiers of pooled products sometimes offer a dedicated instance as an upgrade. The vendor knows what the separation is worth, and charges for it.
Why Multi-Tenant CRM Won
Pooled tenancy won because it made software cheap enough to sell by the seat for a few dollars a month. It deserves credit for that.
- Marginal cost near zero. Adding the ten-thousandth customer to an existing database costs almost nothing. Adding a ten-thousandth database does not.
- One thing to upgrade. Ship a change once and every customer has it. In a siloed world you run it once per customer and deal with the ones that fail.
- Shared capacity. Most customers use very little most of the time, so one pool of resources absorbs everyone's busy moments instead of each customer paying for idle capacity.
- One system to watch. One deployment to monitor, back up, patch and get paged about.
That is a genuine engineering achievement, not a shortcut. It is also an economic decision, not a security one.
What Made Single-Tenant Affordable Again
The pooled model was designed when a database meant a server somebody bought, configured and kept running. Three things moved.
- Managed databases turned provisioning into an API call. Creating a separate database is a scripted step, not a purchase order.
- Infrastructure-as-code turned "one deployment per customer" into a loop. The per-deployment work that made siloing impractical is now mostly automation.
- Serverless and static hosting removed the always-on cost floor. A deployment nobody is using no longer means a server sitting idle with a bill attached.
None of that makes isolation free.
It moved from "prohibitive at any scale" to "a real but manageable cost", and most CRMs are still built around the old number.
Shared tenancy isn't a security decision anyone made. It's an economic decision from an era with different numbers.
Single-Tenant vs Multi-Tenant CRM, Compared
The honest comparison is a trade: multi-tenant wins on price and convenience, and single-tenant wins on how bad the worst day can get.
| Multi-tenant (pool) | Single-tenant (silo) | |
|---|---|---|
| Where your records live | In tables shared with every other customer | In a database only your business uses |
| What separates you | A filter the software must apply every time | The system boundary itself |
| One isolation bug reaches | Potentially every customer | One business |
| Price per customer | Lowest | Higher |
| Upgrades | Everyone at once, on the vendor's schedule | Rolled out per deployment |
| Customisation | Settings the vendor exposes | The system can be shaped to the business |
| Leaving | An export filtered out of a shared system | A copy of your own system |
When a Multi-Tenant CRM Is the Right Choice
Isolation is not always correct, and a post that said so would be selling rather than explaining. Shared tenancy is the right answer when:
- The data is low-sensitivity: public content, preferences, nothing confidential.
- The price has to be genuinely low. Free tiers and cheap tools can't carry per-customer infrastructure, and pretending otherwise means the product doesn't exist.
- You're still finding out whether you need a CRM at all. Start cheap and move when the data starts to matter.
- Switching costs are low anyway, because there isn't much history to move.
Once a CRM holds the operational record of a business, meaning customers, contracts, financials and years of correspondence, none of those conditions hold. That is where the trade stops making sense.
What a Single-Tenant CRM Demands From Whoever Runs It
Isolation stays rare even now, and the infrastructure bill isn't the reason. The discipline is.
- Setting up a new customer has to be fully automated, or it stops scaling after a handful.
- Every upgrade has to reach every deployment, with a plan for the ones that fail.
- Monitoring has to see across deployments without mixing their data.
- Configuration has to be declarative, or each deployment drifts into a one-off.
- Someone has to be able to say, at any moment, which version each customer is on.
Shared tenancy isn't chosen because engineers misunderstand the security trade. It's chosen because the alternative demands automation most teams never built, and nobody builds it unless isolation was the plan from the start.
Four Questions to Ask Any CRM Vendor
You don't need to understand the architecture to learn which model you're buying. Ask these, and listen for how comfortable the answers are.
- Is my data in a database shared with other customers? A straight yes or no is a good sign either way.
- Is a dedicated instance available, and what changes if I take it? If it exists, the vendor has already priced the difference.
- If another customer's account were breached, how would you know whether mine was reached?
- If I leave, do I get my whole system or an export? Ask for a sample export before you need one.
We build single-tenant systems, so weigh this accordingly. Araptus Doon gives every client their own application, database and keys. That only works because we committed to isolation early, when the client count was small enough to build the automation before it was needed.
That's the honest reason it works here: not superior architecture, but an operational cost paid up front, on purpose.
The bottom line
Multi-tenant was the right answer to an old price list.
It's worth checking whether that trade still fits the data your CRM holds.
