Multi-tenancy

When software shipped on discs and installers, every new customer meant another copy of the product installed on that company's own servers. A hundred customers meant a hundred copies running out in the world, and those copies drifted apart over time. One was still on a version from two years ago. Another had a few lines changed to suit that company's process, and nobody outside that account remembered what had been changed.

Support calls all started the same way. A customer would report that a button wasn't on their screen, and the first question back was always which version they were running. A bug fix reached people only after somebody traveled to the site and installed it, so an urgent patch took six months to reach the whole customer base.

Once browsers got good enough to carry a real product, SaaS — software you subscribe to instead of installing — took over. Moving to the web didn't solve the problem by itself, though. Spinning up a separate set of servers per customer just moved the installation from their building to ours while leaving the number of copies untouched. Multi-tenancy is the step past that: run one copy, and draw the customer boundaries inside it.

It keeps the number of systems to operate at one, however many customers sign up. Three things follow from that.

1. Cost. When 300 companies share the same pool of servers, the capacity one company isn't using at 3 a.m. is capacity another company is using. Ten times the customers does not mean ten times the server bill, and that is a large part of why SaaS companies post gross margins of 70 to 80 percent.
2. Releases. Push a new version once and all 300 companies are looking at the same screens that day. When something has to differ per customer, the codebase doesn't fork — a feature flag, a switch that turns a shipped feature on or off, handles it.
3. Operations. One place to look when a page gets slow, one place to search when errors spike. With a hundred separate environments, finding which one broke is a step of its own.

That leaves the question of what actually separates the data. The usual answer is a customer identifier stamped on every row, with every query filtered by it. The weak point is that a person writes that filter. Miss it in one query out of several hundred and a document belonging to one company appears on another company's screen.

So teams add something that doesn't depend on remembering. Row level security (RLS) is a database feature that checks access permission row by row. Forget the filter in a query and the database still refuses to hand over rows belonging to anyone else.

There are three other shapes for delivering the same product, and one company often uses more than one of them at once.

1. Single-tenancy gives each customer their own servers and their own database. Banks and public agencies that contractually require their data to sit apart from anyone else's can only be served this way. The price is that a hundred customers means a hundred environments to run and a hundred deployments per release, which is why it usually sits behind a plan priced several times higher.
2. On-premise installs the product on the customer's own hardware. For organizations whose networks are cut off from the public internet, nothing else works. The contracts are large, which is the appeal, but the version fragmentation of the installed-software era comes back with them.
3. White label strips the maker's name off the product and puts the customer's brand on it. This one answers a different question — whose name it sells under rather than where the servers sit — so it can sit on top of a multi-tenant system rather than replacing it.

Middle positions are common in practice. Application servers stay shared while the database gets pulled out for a handful of large accounts, which buys the separation those customers ask about without doubling the operational load for everyone else.

"We're multi-tenant, so per-customer changes only go as far as configuration."

Forking the code for one account isn't something the team does.

"That account has a data separation requirement, so we can't take them on multi-tenancy."

A security clause means this deal needs its own environment.

"Before release, check there's no query missing the tenant ID filter."

Leave the customer boundary off a query and data leaks across accounts.

At Pagedeck, Sofia brought in a prospect with 2,000 employees, and a security questionnaire arrived with it. One question asked whether the customer's data would be stored in the same database as other customers' data. Pagedeck's honest answer was yes.

What Theo explained in that meeting was the shape of the boundary: a shared store, a customer identifier on every row, and a database that enforces the line itself rather than trusting each query. The SOC 2 report showed that the control had been through an outside audit. If the answer still comes back demanding separate storage in the contract, only one option is left, and Grace decides whether to open a plan priced at three times the standard one.

The most common misreading is hearing "shared database" as "mixed-together data." Sharing does sound like an absence of walls, so the assumption is a fair one. In practice the boundaries stack: the identifier on each row, the filter on each query, and the permission check the database performs on its own. Claiming there is no risk would be just as wrong, though. The boundary is made of code, so one mistake can expose everything at once, which is exactly why teams layer on controls that don't rely on a person remembering. Miss that distinction and the sales conversation turns into repeating the word "secure," which is not an answer a questionnaire accepts.

The other frequent misreading is that customer-specific requests are impossible. One shared codebase makes it sound that way, but logos, permission structures, approval steps and retention rules all sit in configuration and can differ per account. What's hard to accept is a request to branch the code path for one customer. Take that request once and every future release carries an extra thing to verify; take it ten times and the single system the model existed to preserve is gone.