Single-tenancy

Software as a service (SaaS) — software you subscribe to rather than install — brought prices down by having many customers share one copy. Put 300 customer organizations on one set of servers and a tenfold increase in customers does not cost ten times as much. Ship a feature once and all 300 are on the same version the same day.

Some customers could not be taken on that way. Security review documents at banks, insurers, and public agencies carry a line stating that their data must not sit in the same store as another company's. A deal can be fully negotiated and still fail to get signed over that one line, after months of work on everything else in the document.

It's not a place where sales explaining that separation is complete at the logical level helps. The reviewers are not assessing how well the software is built; they are checking whether a written requirement is met. When a contract worth $230,000 a year keeps falling through on the same line, carving out a separate environment for the customers who ask for it becomes its own price tier.

What single-tenancy solves is deals getting blocked by a requirement that data not share a store with anyone else's. Run one environment per customer and the requirement is satisfied as written. Four things actually get resolved.

1. Storage separation — each customer gets a genuinely different database. Unlike a structure that divides rows inside one database by a customer identifier, there is no structural way for a badly written query to return another customer's records. This is usually the exact point a security review is asking about, and it is also the answer that takes one sentence rather than an architecture diagram.
2. Fault and load isolation — one customer exporting 80,000 documents at once doesn't slow anyone else's screen. Where 300 organizations share servers, one heavy job shows up directly in the response times of the other 299.
3. Control over deploy timing — updates can follow a customer's calendar. Contracts often include a clause that nothing may be shipped during quarter-end close, and a separate environment means that one customer can be held still.
4. Data residency — when data has to stay inside a particular country, only that customer's environment gets placed in that region. In a shared structure the same demand would mean moving everybody, which is rarely a trade worth making for one contract.

The price is operational volume. A hundred customers means a hundred environments to run and a hundred deployments for every single feature. The IaaS bill for rented servers multiplies by environment count too. So this sits on a separate tier priced several times higher, with a cap on how many customers get accepted onto it.

Several approaches answer the same demand, so the choice follows how strong the requirement actually is. Four get compared.

1. Multi-tenancy — the default structure where many customers share one copy of the system. Cheapest, and one deployment covers everyone. It can't satisfy the separation requirement literally, but per-customer encryption keys plus access logging often does clear review in practice. Check first whether the requirement is written into a policy document or is a reviewer's concern.
2. Separate databases only — shared servers with a distinct database per customer. This satisfies "the storage is separate" while keeping operational volume below full environment duplication. Load isolation, though, doesn't come with it, so a noisy neighbour is still a noisy neighbour.
3. On-premise — installed on the customer's own servers, the maximum version of separation. Organizations that work only on networks cut off from the public internet have no other option. In exchange the version moves into the customer's hands and can't be fixed remotely, which produces situations where one customer is running a build from two years ago.
4. Regional environments — one environment per country rather than per customer. When several customers share the same national requirement, this cuts the environment count sharply — three countries instead of forty customers. It satisfies residency clauses but not clauses about sharing a store with another company.

White-label delivery, where the product ships under the customer's brand, does not belong on this list. It decides whose name appears on screen, which is a different axis from whether environments are separated.

"This customer won't sign without single-tenancy. It's written into their security review items."

A requirement that logical separation cannot get past.

"We're at six environments and a deploy takes half a day. Automation has to come first."

The environment count has pushed operational work to its limit.

"Find out whether that requirement is in their policy or just a worry first."

If multi-tenancy could clear the review, there's no reason to stand up a separate environment.

Pagedeck sells the shared structure to nearly all its customers and opens separate environments for six large enterprises only. Sofia collects the security review document during the contract stage, and Theo answers each item in a table showing which mechanism satisfies it. Grace put a ceiling on how many customers this tier accepts, because past six environments Theo cannot carry the deployments alone. The cap gets revisited only when deployment stops being something a person does by hand.

The most common mistake is reading separate environments as more secure. Not being mixed with anyone else sounds like the same thing as being safe. But what separation removes is the possibility of another customer's records coming back in a result, while vulnerabilities in the software itself get copied intact into all hundred environments. Some things get worse, in fact. A security patch has to ship a hundred times, and any environment that gets missed leaves that customer exposed the longest. With six environments, having two of them still on last quarter's build is an ordinary occurrence.

Reading a multiplied price as easy margin is the other one. Looking only at the unit price, the arithmetic works. But what grows in this structure isn't only the server bill — it's human hands. Ten customers means deployment, monitoring, and incident response split ten ways, and without automation that gets covered by headcount. Charge three times as much while operational work grows tenfold and every additional contract deepens the loss. Which is why companies opening this tier either cap the customer count or build deployment automation first, and why the tier is usually sold with a minimum contract size rather than a per-seat price.