Multi-Tenant vs Single-Tenant Inventory Software: Which Fits Your Business Group?

If you run one company, this question does not concern you and you can safely stop reading. If you run three companies under one ownership group, a retail arm and a wholesale arm with separate registrations, or a franchise network where each operator keeps their own books, it determines your cost base, your audit exposure, and what happens on the day one of those businesses is sold.

"Multi-tenant" is a word most vendors use loosely, usually to mean "you can add another company." What matters is not the label but where the data sits. Microsoft's guidance for SaaS applications sets out three distinct patterns, and the difference between them is measurable (Microsoft Learn, retrieved 2026-08-13).

Key Takeaways

• There are three patterns, not two: standalone single-tenant, multi-tenant with a database per tenant, and multi-tenant with sharded shared databases (Microsoft Learn, retrieved 2026-08-13).
• Database-per-tenant is the pattern that gives high isolation without high cost, scaling to "well over 100,000 databases" while keeping per-tenant restore simple (Microsoft Learn, retrieved 2026-08-13).
• Sharded shared databases are cheapest per tenant, but Microsoft notes they "necessarily sacrifice tenant isolation" and carry "an increased risk of encountering noisy neighbors."
• Restore is the question buyers forget. Restoring one company to yesterday should not require restoring, or risking, anyone else's data.
• For a group of separate legal entities in Bangladesh, isolation is a compliance question as much as a technical one, because each entity has its own BIN, its own VAT position, and potentially its own auditor.

The Three Patterns, Explained Without the Jargon

A tenant is a customer or a business unit whose data must stay separate from everyone else's. The pattern is where that separation is enforced.

Standalone single-tenant gives each tenant its own application instance and its own database, deployed separately. Complete separation, and the model Microsoft describes as "the most expensive solution from an overall database cost perspective" (Microsoft Learn, retrieved 2026-08-13). This is what a traditional on-premise installation looks like when moved to the cloud without redesign.

Multi-tenant with a database per tenant runs one shared application serving all tenants, while each tenant gets a dedicated database provisioned when they sign up. Microsoft's assessment is that "the use of single-tenant databases gives strong tenant isolation," while pooled resources make it cost-efficient, and that per-tenant recovery "has no impact on other tenants."

Multi-tenant with sharded databases puts many tenants' data together in shared databases, separated by a tenant identifier column in the tables. Cheapest per tenant and effectively unlimited in scale, and the model Microsoft describes as one that "necessarily sacrifices tenant isolation" with "an increased risk of encountering noisy neighbors, where the workload of one overactive tenant impacts the performance experience of other tenants."

The third model is what most low-cost SaaS platforms actually run, whatever the marketing page says.

How They Compare

The pattern in the table is worth stating plainly: database-per-tenant is the only model that scores well on both isolation and cost. Standalone buys isolation with money. Sharding buys cost savings with isolation. Database-per-tenant sits between them and, for a business group with a handful of companies, it is almost always the right answer.

Four Questions That Decide It For You

1. Are your businesses separate legal entities?

If your retail arm and your wholesale arm are separately registered, each has its own BIN, its own VAT return, and potentially its own auditor. A tenant identifier column in a shared table is a weak boundary for that. Any bug in a query filter, and one entity's transactions appear in another's report. In a shared-database model, the correctness of your legal separation depends on every query in the application being written correctly, forever.

With a database per tenant, a query against Company A's database cannot return Company B's rows, because those rows are not there. The boundary is structural rather than conditional. If your entities file separate VAT returns, this matters. Mushak 6.3 invoicing covers why each registered entity needs its own invoice sequence and VAT position.

2. Might you sell, spin off, or hand over one of them?

This is the scenario that exposes architecture fastest. When you sell one business, the buyer wants its data. All of it, and none of anyone else's.

With a database per tenant, that is a database export. With a shared sharded database, it is an extraction project: someone writes queries to pull one tenant's rows from every table, and someone else has to certify that nothing was missed and nothing extra was included. The same problem appears when a franchisee leaves, when a partner exits, or when a regulator requests one entity's records.

3. What happens when someone deletes something important?

Ask every vendor this and listen carefully: can you restore my company alone to yesterday, without touching any other customer?

Microsoft's guidance is direct on this. With a database per tenant, recovery "only needs to restore the one single-tenant database that stores the tenant" and "has no impact on other tenants." With sharded databases, restoring a tenant to a prior point in time is more involved, because you are restoring a database containing other tenants' data too, and then reconciling (Microsoft Learn, retrieved 2026-08-13).

In practice, a vendor on a shared model will often decline a single-tenant restore, because the risk to other customers is unacceptable. That is a reasonable position for them and a bad outcome for you.

4. Do your businesses need to differ from each other?

Different companies within a group frequently need different things: a pharmacy needs batch and expiry tracking, a hardware wholesaler needs multiple units of measure, a service business needs neither. Microsoft notes that with a database per tenant, "customizing the schema for one or more individual tenants is straightforward to achieve." In a shared schema, one tenant's requirement becomes a column every tenant carries, and the schema accumulates fields that most customers will never use.

What Multi-Tenant Actually Buys a Business Group

Set the architecture aside for a moment and look at the operational result.

One subscription, not three. The most immediate effect. Instead of buying and administering a separate system per company, you run one platform and add businesses to it. For a group of three, this typically changes software cost by a factor rather than a percentage.

One login, separate books. Owners and group accountants switch between businesses without logging out. Each business keeps its own products, warehouses, customers, suppliers, chart of accounts and VAT position. Staff see only the businesses they are assigned to.

Consolidated reporting where you want it, isolation where you need it. Group-level stock value and profitability across all businesses, while each entity's statutory reports stay clean and separate.

One upgrade path. Every business gets improvements at the same time. With three separate installations, you get three versions, three upgrade schedules, and eventually three different sets of behaviour that nobody can reconcile.

Per-business branding. Each company issues invoices under its own name, logo and BIN, which is a requirement rather than a preference once the entities are separately registered.

Questions to Ask a Vendor

Vendors will answer "yes, we're multi-tenant" to almost any framing of the question. These get past that.

1. Is my data in a separate database, a separate schema, or a shared table with a tenant ID column? The answer places them in one of the three patterns. Any hesitation is informative.
2. Can you restore my business alone to a point in time, without affecting other customers? Ask for the procedure, not a yes.
3. If I leave, what exactly do I get? A full database export, or a set of CSV files someone assembles by hand?
4. Can one customer's usage slow down my system? Ask specifically how they isolate resources between tenants.
5. Can two of my businesses have different configurations? Different VAT rate sets, different modules enabled, different chart of accounts.
6. Where is the data hosted, and who can access it? Relevant for both compliance and practical latency.
7. How do you prevent one business's document sequence appearing in another's? Invoice numbering is a specific and revealing case.

Frequently Asked Questions

Is multi-tenant less secure than single-tenant?

Not inherently, and the framing is imprecise. Microsoft rates both standalone single-tenant and database-per-tenant as high on tenant isolation, and only the sharded shared-database model as low (Microsoft Learn, retrieved 2026-08-13). A well-built database-per-tenant platform separates your data more reliably than a poorly maintained single-tenant server that nobody has patched in two years.

Does multi-tenant mean my competitors can see my data?

No. Tenant isolation exists precisely to prevent that. The question worth asking is how strongly it is enforced: structurally, by giving each tenant its own database, or conditionally, by filtering a shared table on every query.

Can I run different currencies or countries per business?

That depends on the product rather than the architecture, but database-per-tenant makes it considerably easier, since configuration differences do not have to be accommodated in a shared schema. If you operate across borders, ask to see two businesses configured with different base currencies before you commit.

What is a noisy neighbour?

One tenant whose heavy usage degrades performance for everyone sharing the same database. Microsoft identifies this as a specific risk of the sharded multi-tenant model (Microsoft Learn, retrieved 2026-08-13). In practice it shows up as a POS that is slow at 6pm on a Thursday for reasons nobody at your business can explain.

I only have one company. Does any of this matter?

Only two parts. Ask about per-tenant restore, because losing data is possible for any business. And ask about data export, because it determines whether switching vendors later is a migration or a rebuild.

Is a multi-tenant platform cheaper than separate systems?

For a group, generally yes, because you buy one subscription instead of several and administer one system instead of several. Compare total cost including administration, not just licence fees. The Bangladesh inventory software buyer's guide covers realistic pricing tiers.

Making the Decision

Count your legal entities. If the answer is one, choose on features and ignore this article. If the answer is more than one, ask the seven vendor questions above, and treat the restore answer as the deciding one, because it reveals the architecture regardless of what the marketing page claims.

For most business groups, database-per-tenant is the model that fits: strong separation between your companies, one system to administer, one bill, and the ability to hand over a single business cleanly if you ever need to.

Once the architecture question is settled, the operational work is the same as any other implementation. Multi-warehouse inventory management covers running stock across locations, and barcode setup covers making the data accurate at the point of entry.

PicoStore runs database-per-tenant isolation, so each of your businesses keeps its own data, branding and books under one login. Start free and add your second business in minutes.

Sources

• Microsoft Learn: Multitenant SaaS patterns, Azure SQL Database