• Instance => SQL Server
• CDB => Master database
• Seed => Model
• PDB => User database

No, the comparison isn’t exact, but you can find similarities if you focus on the underlying concepts. When confusion arose around Oracle pluggable databases compared to the previous single-instance architecture, I initially couldn’t understand why it was so difficult for others to grasp. Then, I searched for architectural diagrams, and it started to make sense.

Earlier Oracle architectures were detailed yet followed a consistent, familiar structure. Regardless of the version, the database architecture was designed in a way that made it easy to identify what components were part of the Oracle database. Using the following examples, you’ll see how this clarity in design carries through, even as the technology evolves.  If you refer to some of the earliest architecture diagrams available on the web, you may see something like the following:

 

Even if it doesn’t go into deep detail, the above diagram shows some basic information about Oracle for the novice that’s essential-

• Instance
• SGA, with understanding that you have different caches and buffers managing areas of memory management.
• Background processes
• Datafiles, configuration files, control files and redo logs.
• Archived log files for recovery

It would show a process, connecting to a database instance, the background processes, database files, etc.

Simplicity Isn’t Always Best

It’s challenging to reconcile the newer multitenant architecture with the traditional single-instance Oracle architecture, and that’s when it clicked—I finally understood the difficulties that newcomers to Oracle were experiencing.

For someone new to the platform, it’s already daunting to grasp the core concepts of Oracle’s database architecture. Adding the layers of abstraction introduced with multitenant—like the container database (CDB) and pluggable databases (PDBs)—only adds to the confusion. Without clear, detailed diagrams showing how the two architectures align and differ, it’s easy to see why people feel overwhelmed.

As I kept searching for resources, most of the diagrams I found mirrored the initial, overly simplistic visuals. These high-level illustrations lacked the technical depth needed to explain how single-instance components map to multitenant counterparts. The missing details—like the relationship between the root container and PDBs, or how shared resources like memory and processes work—only made the learning process harder. It became evident that while these diagrams served as an introduction, they didn’t address the real questions users had, leaving a significant gap in understanding for anyone trying to make the transition, and yet I find repeat of the cartoonish diagrams everywhere:

The detailed explanations of Oracle’s background processes and memory structures, once a staple of Oracle architecture documentation, had been replaced with oversimplified metaphors, like a USB drive representing a pluggable database (PDB). While this analogy may have made the concept approachable, it left much to be desired in terms of technical clarity. There was little visual or written explanation of how Oracle’s older single-instance architecture compared to the newer multitenant model. Key questions remained unanswered: Which background processes now belonged to the container database (CDB)? Did any processes or responsibilities shift to the PDBs? These gaps left many users, especially those transitioning from older Oracle versions, struggling to connect the dots.

Diagrams and Docs

In response to this lack of clarity, I began creating our own internal documentation. This included more detailed diagrams aimed at bridging the gap between versions, clearly breaking down the evolution of the architecture while maintaining accessibility for a broad audience. The goal was to illustrate not only the distinctions between single-instance and multitenant architectures but also how they relate, enabling a smoother learning curve.

For example, the new single-instance diagrams, while still high-level to ensure readability, explicitly show the components and processes typical of pre-multitenant days. These visuals highlight the elements contained within a single instance—memory structures, processes, and storage relationships—offering a clear snapshot of what a single-instance Oracle database looked like before multitenancy. By doing so, the documentation provides a solid foundation for users to compare the traditional architecture with its multitenant counterpart, making the transition far less daunting.  I used colors to help match concepts, even if terms changed between the architecture:

To further enhance the clarity and usability of the diagrams, I’ve included the Oracle database version for which each architecture is valid in the bottom-left corner of every diagram. This small but significant detail provides essential context, helping users immediately understand which version of Oracle the diagram applies to. By doing so, it eliminates guesswork and ensures that the diagrams are both time-relevant and aligned with the user’s specific Oracle environment.

For example, the single-instance architecture diagram now clearly indicates that it is applicable up to Oracle 21c Oracle databases. This makes it easier for users to anchor their understanding of traditional Oracle architecture before diving into the multitenant model and to know when to check if it could be either. Similarly, diagrams for multitenant architecture include version labels starting from Oracle 12c, showing when this feature was introduced and became the standard.

Comparisons Welcome

By providing this context, users can directly compare the two architectures side by side. They can see not only the shared elements but also how the introduction of multitenant architecture added layers of abstraction, such as container databases (CDBs) and pluggable databases (PDBs). This versioning detail enhances the diagrams’ educational value and supports a more logical progression in understanding. It’s my hope that this approach makes the transition from single-instance to multitenant architectures clearer and more intuitive, empowering both new and experienced Oracle users to grasp the evolution of the database technology with confidence.

This understanding becomes even clearer when we draw comparisons to Oracle RAC (Real Application Clusters) database architecture. RAC, which has long been a cornerstone of Oracle’s instance resiliency and scalability solutions, provides a useful point of reference for understanding differences in the previous architectures and how they evolve. By comparing single-instance, RAC, and multitenant architectures side by side, the distinctions and similarities become easier to grasp.

The embedded diagrams are integral to a larger set of documentation that dives deeply into Oracle database architecture, providing a comprehensive and detailed view. While the diagrams themselves offer clear, high-level representations, they are supported by accompanying documentation that explains the architecture in far greater detail. This includes advanced discussions on topics such as background processes, memory management, caches, and buffers, as well as a closer look at the Program Global Area (PGA) and how these components interact within different architectures.

Although I’ve seen various resources that cover these topics well, they are often scattered across different documents, books, or online materials. None of them consolidate this information into a single, cohesive resource that combines foundational architecture with detailed technical insights. This fragmented approach frustrated me as much as it likely did those who were trying to learn, as it created unnecessary barriers to understanding the bigger picture.

By embedding these diagrams into a unified document, I aim to provide a complete resource that bridges the gap between introductory and advanced material. The goal is to guide learners step-by-step—from the basics of Oracle architecture to its most intricate details—while offering a clear and structured learning path. This approach not only simplifies the learning process for newcomers but also provides seasoned professionals with a valuable reference that they can use to refresh or expand their knowledge.

I’m going to share some of what I’m building here, too, as I believe it has to be frustrating for others going through this, too.