Multitenant Database Containers: One Database, Many Tenants

Multitenant database containers are databases designed to hold many tenants inside one shared container. A tenant is one customer: one company, one team or one application whose data must stay separate from everyone else’s. In the original design, which comes from Oracle, one container database holds many smaller databases, and each of those smaller databases serves one tenant. The tenants share the machinery of a single database while they keep their data, their users and their settings apart.

The phrase does a second job in cloud writing, where people use multitenant database containers as a general label for any database setup that keeps many customers inside one system. The two meanings overlap, and that overlap confuses readers. This guide keeps them apart. It explains the Oracle design first, part by part, and then compares the wider patterns that software as a service (SaaS) teams choose between, with the trade-offs stated plainly.

The problem Oracle built containers to solve

Before Oracle Database 12c, every Oracle database stood alone. Oracle calls that older design a non-CDB. A company with hundreds of databases ran hundreds of separate instances, each with its own memory, its own background processes and its own administrator routine. Oracle’s own documentation describes the waste plainly: large enterprises may run hundreds or thousands of databases on many servers, and each database often uses only a fraction of its server’s capacity, while administrators repeat the same patching, backup and tuning work database by database.

Consolidation was the obvious answer, and the old workarounds all hurt somewhere. Virtual machines copied whole operating systems and used resources inefficiently. Several standalone databases on one server still shared nothing, so each one needed separate care. Squeezing every tenant into one database as separate schemas shared the machinery, but it demanded application changes and blurred the line between one tenant’s data and the next. Oracle built the multitenant architecture to consolidate databases without those compromises: many databases inside one, and each one keeps the behavior of a standalone database.

Inside the container: root, seed and pluggable databases

Oracle names the outer database a multitenant container database, or CDB. Oracle’s Multitenant architecture overview describes every CDB as a set of containers, and the fixed parts are the same in each one:

• The root, named CDB$ROOT. The root holds the material that belongs to the whole container: Oracle-supplied metadata, such as the source code for Oracle’s own PL/SQL packages, and the common users covered below. The root holds no tenant data, and Oracle advises against adding any.
• The seed, named PDB$SEED. The seed is a system-supplied template. The CDB copies the seed to create new PDBs quickly, and nobody adds or changes objects inside it.
• The pluggable databases, or PDBs. These are the working databases that administrators create. A PDB holds the data and code for one set of features or one tenant: an HR application in one PDB, a sales application in another, a billing tenant in a third.

From the operating system’s point of view, the CDB is the database: it owns the files, the instance and the processes. From an application’s point of view, its PDB is the database. An application connects to a PDB and sees a normal, separate Oracle database, with its own data dictionary, its own users and its own settings. It never touches the root or the seed, and it cannot see the other PDBs around it. Oracle puts it directly: users interact only with the PDBs. That split is the whole trick of multitenant database containers: one database to run, many databases to use.

Common users and local users

One CDB can hold databases for rival teams or even rival companies, so the design splits user accounts in two. A common user is a database user that is known in every container in the CDB. It holds one identity across the root and all the PDBs. Oracle’s built-in SYS account works this way, and a common user with the right privileges can manage the whole CDB or step into any PDB.

A local user exists inside one PDB only. It can work in that PDB and nowhere else, and privileges granted inside a PDB stay inside that PDB. This split lets one central administrator run the container while each tenant keeps its own administrator, locked to its own database. Oracle lists this secure separation of duties among the design’s main benefits, because a mistake or a compromised account in one PDB does not hand over the keys to the others.

Why teams consolidate into one container

The savings come from sharing the expensive parts. One hundred PDBs on a single server share one database instance, in Oracle’s own example, instead of one hundred instances that each hold memory and run background processes. The hardware does more useful work, and the team sizes one shared memory pool instead of a hundred separate ones. Oracle calls this the cost reduction at the heart of the design.

Daily work shrinks the same way. The administrator patches one database instead of a hundred, and upgrades one database instead of a hundred. A backup strategy can cover the whole CDB in a single operation for all hosted tenants, and Oracle’s availability features also work at the level of a single PDB when one tenant needs its own recovery. When a tenant’s database has to move, an administrator unplugs the PDB from one CDB and plugs it into another. That move doubles as a fast upgrade path: unplug from the old release, then plug into a CDB that runs the new one.

Sharing creates one risk with a plain name: the noisy neighbor, a tenant whose heavy workload slows everyone nearby. Oracle’s answer is Oracle Resource Manager, which lets administrators create resource plans that allocate resources among PDBs, so one busy tenant cannot starve the rest. Sharing never removes the need for that kind of control. It makes the control possible in one place.

How the container became the only option

Oracle introduced the multitenant architecture with Oracle Database 12c, and the same release started the clock on the old design. Oracle’s upgrade guide records that the non-CDB architecture was deprecated starting with 12c release 1, with a warning that it could be desupported in a future release. The warning became fact in Oracle Database 21c: non-CDBs are desupported there, the database installers can no longer create them, and the same guide states that a multitenant container database is the only supported architecture in 21c and later releases.

For anyone who runs Oracle today, the practical meaning is short. Every new Oracle database is a CDB, even when it holds a single PDB, and an old non-CDB that upgrades to a current release must first become a PDB inside a CDB. The container stopped being one option among two and became the shape of the product itself.

The second sense: multitenant database containers in SaaS

Outside Oracle, teams use the language of multitenancy for a business problem: one software product, many customers, and a hard rule that no customer ever sees another customer’s data. A SaaS provider picks a database pattern for its tenants, and that choice sets the price of the service and the strength of the walls between customers. The container design is one answer. The full menu has three main patterns, and multitenant database containers sit in the middle of it.

At one end, each tenant gets a separate database. Isolation is total, and a provider can restore one customer’s data without touching anyone else, but every database needs its own patching, tuning and watching, so the cost climbs with every customer who signs up. At the other end, all tenants share one schema, one set of tables, and a tenant column marks which rows belong to whom. This shared design costs the least to run and carries the most risk: every query must filter by tenant, one bug can expose rows across customers, and a restore brings back everyone at once. Some teams soften the shared design with a separate schema per tenant inside one database, which keeps tables apart while the tenants still share one instance.

The container pattern plants a real database boundary around each tenant, like the separate database pattern, but keeps every tenant inside one managed container, like the shared pattern. In Oracle’s version, each tenant’s PDB carries its own users, its own data dictionary and its own data files, so the boundary is a true database boundary, while the provider still patches and backs up a single container.

As tenant counts grow into the thousands, providers spread tenants across many servers and regions, and the platform starts to behave like the systems in our explainer on what a distributed system is, with routing layers that send each tenant to the machine that holds its database. Fewer and larger databases also change the wiring around them: fewer endpoints to connect, sync and monitor, which is the daily concern of enterprise application integration.

The honest trade-offs

Choosing a tenant pattern is a software architecture decision that is expensive to reverse, because it shapes every query, every backup and every customer migration that follows. The trade-offs of multitenant database containers are the trade-offs of sharing itself, and buyers should hear them stated plainly.

Tenants inside one container share one instance and one machine. A failure at that level touches every tenant at once, and a container-wide patch lands on every tenant in the same maintenance window. Resource plans soften the noisy neighbor problem, yet they cannot create capacity that is not there: a container sized for average load will still feel an exceptional day. Operations teams answer with close monitoring of the shared host, and at the hardware level the server reports faults upward through alert mechanisms such as the platform event trap, so a sick machine gets flagged before every tenant on it notices.

Two more honest limits deserve a mention. The container design described here is Oracle’s, so the skills, the tooling and the licensing follow Oracle’s rules, and a team that leaves Oracle leaves the CDB model behind. And isolation inside one database is logical isolation: strong, and enforced by the database itself, but not the same as separate hardware. A regulated tenant that needs physical separation still belongs on a database of its own.

Conclusion

Multitenant database containers put many private databases inside one shared container. Oracle’s version, the CDB with its root, its seed and its pluggable databases, turned that idea into the only architecture Oracle supports. SaaS teams use the same thinking to place each tenant somewhere on the spectrum between one shared schema and a database of their own. The right spot on that spectrum depends on two things: how much isolation your tenants truly need, and how much database you can afford to run for each of them.