Oracle Database

Oracle Database is the reference enterprise relational engine: a converged system where relational, JSON, graph, spatial, and (since 23ai) vector data live under one engine, one transaction model, and one backup story. It is also a licensing universe - the price of a feature is often its dominant attribute, so this page pairs the architecture with the commercial reality that shapes how it actually gets deployed.

Multitenancy: CDB and PDBs

Since 12c the architecture is multitenant: one container database (CDB) hosts many pluggable databases (PDBs). The CDB carries the shared infrastructure - redo, UNDO, background processes, memory - while each PDB looks like a complete database to the application.

Why it matters: consolidation. A hundred application databases run as a hundred PDBs sharing one CDB’s overhead, patched and cloned together, yet isolated for security and (with resource manager) performance. Clone a PDB is a metadata-class operation - CREATE PLUGGABLE DATABASE ... FROM copies near-instantly.

RAC: shared-everything scale-out

Real Application Clusters runs one database across multiple nodes sharing the same storage. Unlike sharding, every node sees all data; unlike a standby, all nodes serve reads and writes simultaneously. Cache Fusion keeps buffer caches coherent across nodes.

RAC buys two things: survival of instance failure in seconds (sessions fail over via TAF/FAN) and read-throughput scale-out. It does not give write scale-out the way sharding does - all nodes still write the same storage, and hot-block contention between nodes is a real tuning discipline. RAC is also separately licensed, expensive, and operationally demanding; it earns its cost only where seconds of downtime or read scale are genuinely priced in.

Data Guard: the replication that is actually used

Data Guard ships redo to one or more standby databases. Physical standbys are block-identical and can open read-only (Active Data Guard, separately licensed) for report offload; logical standbys replay as SQL for heterogeneous reporting. Fast-Start Failover automates promotion.

This is the mature path for DR: synchronous for zero data loss where latency allows, async for distance. Maximum Availability / Maximum Protection / Maximum Performance modes are the data-loss-versus-latency dial.

The converged engine

Inside one SQL surface: relational tables, JSON (native JSON type since 21c, JSON-relational duality views), property graphs (PGQL), spatial, text, and - since 23ai (continuing under the 26ai name) - VECTOR columns with vector indexes for AI Vector Search. The pitch is one security model, one transaction log, one backup across all of it. The counterpoint is that each converged feature is shallower than a dedicated engine at the extreme end.

PL/SQL and the optimiser

PL/SQL runs inside the engine - packages, triggers, stored procedures with decades of enterprise code written in it. The cost-based optimiser is genuinely excellent: adaptive plans, partitioning smarts, and diagnostics (ASH, AWR) that are industry reference quality - several of those diagnostics being separately licensed packs.

Versions that matter

• 19c: the previous long-term release - still the bulk of production estates.
• 21c: innovation release, added the native JSON type.
• 23ai: the release that introduced AI Vector Search and JSON-relational duality views.
• 26ai: the current long-term support release. It is 23ai renamed - applying the October 2025 release update moves a 23ai instance to 26ai with no database upgrade and no application re-certification.

Feature availability depends on edition: Enterprise plus separately-priced option packs (Partitioning, RAC, Advanced Security, diagnostics packs). Check the edition matrix before designing on a feature.

The licensing reality

Oracle licenses per processor (core-factored) or named user, and option packs stack on top. The free path is Oracle XE (resource-capped) and cloud free tiers. The practical rules: audit what options are enabled (DBA_FEATURE_USAGE_STATISTICS shows what has ever been touched - enabling a pack can create retroactive exposure), negotiate at renewal boundaries, and treat “we will just enable it” as a purchase decision, not a config change.

What actually breaks

• Option pack drift: someone enables Partitioning or Advanced Compression on a standard edition estate; the feature usage report becomes an audit finding.
• RAC hot blocks: sequences and monotonically increasing keys create index-leaf contention across nodes - fix is reverse-key or hash partitioning, not more nodes.
• PDB sprawl: PDBs cloned “temporarily” and never dropped - memory and licensing both grow.
• Assuming cloud-managed means licence-free: bring-your-own-license maths still applies on cloud deployments.

Where Oracle is the wrong choice

New systems without an existing Oracle estate rarely justify it: PostgreSQL covers the relational core plus JSONB and vector search at zero licence cost, and SQL Server covers the Microsoft-aligned enterprise. Oracle earns its price where the estate, the PL/SQL codebase, the RAC/Data Guard operational depth, or the support contract already exists - not where the architecture is a blank page.