Architecture / Ideal Workloads
Distributed SQL, shared-nothing, peer-to-peer architecture. All nodes symmetrical; any node can handle reads/writes. Cluster uses distributed consensus: No matter where data lives, every node can access data anywhere in cluster
SYSTEM OF RECORD. Optimized for transactional workloads that require strong consistency and global distribution, such as AI innovators, cybersecurity, eCommerce & retail, financial services, fintech/payments, gaming, quant/trading & research, and online travel
Centralized Oracle SQL engine with optional RAC (Real Application Clusters) for active-active scale-out on shared storage within a datacenter. CDB/PDB multitenant model for instance consolidation. GDD extension required for true distributed scale-out
ORACLE MODERNIZATION. Best for Oracle users supporting financial services, insurance, telco, and ERP, and those modernizing existing Oracle estates with vector search, RAG, and in-database ML
Sharded shared-nothing built as a layer on top of multiple Oracle Database instances. Separate Shard Catalog coordinates query routing and DDL; Shard Directors handle connection routing. Shards are not peer-to-peer: Catalog and Directors require their own HA configuration, adding significant architectural complexity
DISTRIBUTED OLTP. Designed for Oracle shops requiring horizontal scale, data residency compliance, and high availability, such as fintech, SaaS, and regulated industries where Oracle SQL compatibility and application-level sharding key design are acceptable architectural constraints
Auto-Sharding (Dynamic Re-Sharding Online)
NATIVE & AUTOMATIC. Automatically shards data into ranges and dynamically splits, merges, and rebalances online across nodes based on load and size. Zero downtime, fully transparent
NOT NATIVE WITHOUT GDD layer. Standard Oracle 26ai, including RAC, does not auto-shard. GDD layer is required for horizontal sharding. Re-sharding operations are managed via GDSCTL; less automated and more operationally complex than CockroachDB's continuous automatic rebalancing
SUPPORTED ONLINE. Add or remove shards with some downtime; data automatically rebalances across shards with minimum movement. Initial sharding key design requires significant upfront planning; changing the sharding strategy post-deployment is operationally complex and risky
Automatic Geo-Partitioning (Multi-Region Data Affinity)
NATIVE AND AUTOMATIC. Declarative SQL schema adjustments automatically route, partition, and anchor data close to the user's location, automatically moving data to the region where it is most frequently accessed. Supports geo-partitioning with zone configurations for data locality, compliance, and low latency
LIMITED WITHOUT GDD. Standard Oracle 26ai does not offer native geo-partitioning; data locality requires manual partitioning design or the addition of the GDD layer. Regional OCI database deployments provide some data locality at the infrastructure level without GDD's policy engine
SUPPORTED via automated data placement policies. Policy-driven distribution pins data to specific geographic shards for regulatory compliance and low latency. Six distribution methods available. Less declarative than CockroachDB's REGIONAL BY ROW; requires upfront sharding key design and architectural commitment
Availability including Multi-Cloud and Hybrid
Available on all public clouds, e.g., AWS-Google Cloud-Azure; can run a single logical cluster spanning multiple clouds. Can run on prem/local, and cloud + prem hybrid deployments
Available on Oracle Cloud Infrastructure (OCI), AWS, Azure, and GCP as a managed service; on-premises for Linux x86-64 since early 2026. Hybrid deployments supported via Exadata Cloud Customer
Available on Oracle Cloud Infrastructure (OCI) as a managed service (Globally Distributed Autonomous Database); self-hosted on-premises or multicloud via Oracle Database Enterprise Edition. Managed cloud tier is OCI-only. Multi-cloud deployments are architecturally possible but require self-managed shard, Catalog, and Director infrastructure
Change Data Capture (CDC)
NATIVE. CHANGEFEED command enables scalable, resilient streaming of data changes to Kafka, cloud storage, and webhooks; no third-party CDC tool needed. CDC Queries enable SQL-based filtering and transformation of streams
ONLY WITH GOLDENGATE (separate product, additional cost). LogMiner provides redo log-based change data capture. GoldenGate 26ai adds AI-powered replication for multicloud and streaming pipelines. No native equivalent to CockroachDB's built-in CHANGEFEED command
ONLY WITH GOLDENGATE, which is shard-aware and captures changes across distributed shard redo logs. More complex to configure across a multi-shard topology: each shard maintains an independent redo log that GoldenGate aggregates
Data Anomalies
ZERO under Serializable isolation: all standard SQL anomalies (dirty reads, non-repeatable reads, phantom reads, lost updates, and write skew) are prevented by default with no additional developer configuration. Read Committed is also available for workloads where some consistency relaxation is an acceptable tradeoff for reduced latency
Possible under both supported isolation levels. Read Committed (the default) permits non-repeatable reads and phantom reads. "Serializable mode" is in fact Snapshot Isolation: It prevents dirty reads and lost updates but remains vulnerable to write skew. Developers must explicitly add SELECT FOR UPDATE or table-level locks to close the gap, shifting the burden to the application
Inherits Oracle's two-level isolation model for intra-shard transactions, carrying the same write skew exposure as 26i. Cross-shard transactions add further risk: anomaly surface area grows when transactions span shards, and Oracle's architecture explicitly optimizes workloads to stay shard-local precisely to reduce that exposure. Developer-applied locking remains the mitigation strategy
Data Integrity & Foreign Keys Support
Provides strict ACID enforcement at the storage layer and full referential integrity. NATIVELY VALIDATES FOREIGN KEYS, explicit CHECKs, and transactional constraints to ensure absolute global correctness across global nodes
Strong within a single instance or RAC cluster. Referential integrity, foreign keys, CHECKs, and transactional constraints enforced at the storage layer
WITHIN-SHARD ONLY for referential integrity. Foreign keys, global unique constraints, and cross-shard referential integrity between tables on different shards are not natively supported, which is a significant limitation for complex, normalized relational schemas
Data Model Complexity
LOW. Relational model with strict schemas, normalized tables, joins, and referential integrity. Ideal for managing complex relationships and transactional systems of record; adapts easily to microservices and enterprise legacy systems
LOW TO MODERATE. Rich converged relational model with native support for JSON, graph, spatial, and vector in one engine. Flexible for multi-model workloads but schema complexity grows with the multitenant CDB/PDB architecture and optional GDD extension
MODERATE TO HIGH. Relational model with sharding constraints. Global primary keys, unique constraints across shards, and referential integrity between tables on different shards are not natively supported; the schema must be designed around sharding keys from initial deployment
Data Residency
STRONG, INTUITIVE, AND LOCALITY-AWARE. Helps fulfill compliance (e.g., GDPR, CCPA) with Row-Level Control: can pin specific rows to specific geographic regions using REGIONAL BY ROW command, while preserving single logical data platform. Business and compliance teams can use simple SQL commands to ensure customer data never leaves specific geographic borders
SUPPORTED via policy-driven data placement on OCI. Autonomous Database restricts data to specific OCI regions. On-premises and multicloud data residency without GDD requires manual partitioning discipline and custom data governance controls
STRONG. Automated distribution policies pin jurisdiction-specific data to designated shards and regions for GDPR, DORA, and similar compliance. OCI-managed variant makes this more turnkey. Self-hosted deployments require manual configuration of residency policies across the shard fleet
Developer Tools / Experience / Ease of Use
Rich ecosystem: Local CLI, web console UI, ORMS, BI tools, SQL clients, native DB migration toolkits, language‑specific drivers, and compatibility with standard PostgreSQL developer tools like psql
PostgreSQL wire protocol-compatible; feels exactly like developing on standard PostgreSQL. Fits effortlessly into existing ORMs, drivers, and frameworks
Can be spun up instantly in any environment (AWS, GCP, on-prem) with the exact same management interface. The cluster manages its own data balancing, scaling, and hardware survival automatically; DBAs do not need to be distributed systems experts to keep it running smoothly.
SQL Developer, SQL Developer Web (ORDS), Oracle Enterprise Manager, SQLcl, Data Safe, APEX (low-code app development), OML Notebooks (in-database ML), AI Vector Search tools. Rich but largely Oracle-proprietary toolset; GoldenGate for CDC is a separate licensed product
Oracle SQL and PL/SQL, standard for Oracle developers, not PostgreSQL-compatible. Applications built on other databases require rewrites
Mature and familiar for Oracle-trained DBAs but steep learning curve for organizations without deep Oracle expertise. Autonomous Database on OCI automates tuning, patching, and backups. CDB/PDB multitenant architecture adds complexity for non-Oracle teams
Standard Oracle 26ai tools (SQL Developer, Enterprise Manager, Data Pump) and GDSCTL command-line utility for shard management and Global Services Director. Tooling complexity grows with shard topology. No equivalent to a single-binary, self-managing distributed database cluster
Inherits Oracle SQL dialect from 26ai; not PostgreSQL-compatible. Applications must be designed around sharding keys for optimal performance. Routing is transparent for shard-key-aligned OLTP queries; cross-shard operations require more careful design
COMPLEX. Requires separate deployment and ongoing operation of Shard Catalog, Shard Directors, and individual shard instances, each with its own HA configuration. Independent testing documented documentation gaps, recursive loops, and conflicting guidance in Oracle GDD. Significantly higher operational burden than distributed-native alternatives
Distributed ACID Transactions
Fully distributed, multi-row, multi-table ACID transactions out-of-the-box. Fully supported with serializable isolation using distributed consensus (Raft Protocol) across tables, ranges, and regions; strong ACID guarantees
ACID within RAC cluster on shared storage. Cross-region distributed ACID requires the GDD layer and is not native to standard Oracle 26ai. Active Data Guard standbys are read-only and are not active participants in distributed write transactions
Cross-shared ACID is supported but architecturally limited. Cannot offer global primary keys, unique constraints, or referential integrity between sharded tables. Cross-shard transactions require Shard Catalog coordination, a centralized dependency unlike CockroachDB's peer-to-peer distributed consensus
Enterprise Support
Dedicated 24/7/365 enterprise support directly from Cockroach Labs with strict SLAs and custom engineering channels. Offers global follow-the-sun support (TSE+SRE) with proven reliability and global partnerships with industry leaders. Single Global Incident Management integrates Engineering + Support + Customer Success in one channel for consistency/immediacy
Oracle Premier Support via My Oracle Support (MOS) with global coverage. Diamond tier MAA reference architectures validated by Oracle engineering. Large global partner and SI ecosystem. Support quality reputation is mixed at hyperscale compared to cloud-native vendors
Supported under standard Oracle Database support contracts. The OCI-managed Globally Distributed Autonomous Database offering has stronger managed support than self-hosted GDD
FinOps Support
HIGH. Straightforward pricing based on predictable node usage or consumption metrics. Avoids hidden, fluctuating network traps when moving data across different infrastructure regions. Supports financial governance/FinOps
LOW TO MODERATE. CPU-based or Named User Plus licensing involves layered complexity: Edition × metric × Core Factor × options and packs. Licensing audit risk is significant; options like RAC, Active Data Guard, and Partitioning can be enabled accidentally, creating exposure. OCI cloud pricing is more consumption-based but introduces OCI lock-in
LOW TO MODERATE. Requires Oracle Database Enterprise Edition per shard plus Shard Catalog and Director infrastructure. Multi-shard deployments multiply licensing exposure across the fleet. OCI-managed tier offers consumption-based pricing but locks to OCI. Self-hosted deployments dramatically increase audit risk. No native FinOps dashboarding
Follower Reads
SUPPORTED. Supports follower/replica reads with Bounded (controlled) Staleness, allowing low‑latency local reads from nearby replicas while keeping strong global ordering
Read-only Active Data Guard standbys (synchronous or asynchronous) serve read traffic from a regional standby. True Cache in 26ai provides application-transparent, in-memory read caching
Read-only replicas available within each shard via Active Data Guard or Raft followers. GDD Global Services routes read-only queries to the nearest replica within a shard replication group. Less unified than CockroachDB's bounded-staleness follower reads across the full cluster as a single logical database
FREEDOM
ZERO VENDOR LOCK-IN. Runs on any public or private cloud, across multiple clouds, via CockroachDB's Bring Your Own Cloud (BYOC) offering, on-premises, bare metal, Kubernetes, self-hosted, or in a hybrid deployment encompassing some or all of these. Business Source License (BSL) but Source Available. Full commercial-grade support directly from CockroachDB
TOTAL VENDOR LOCK-IN. Oracle SQL dialect, PL/SQL, and proprietary tooling (GoldenGate, APEX, RAC, Data Guard) make migration to other databases extremely difficult and costly. Most feature-complete on OCI. Oracle licensing audits are a known commercial risk. Customers typically negotiate to below list but remain contractually bound within Oracle's ecosystem
TOTAL VENDOR LOCK-IN. Applications are sharding-key aware and Oracle SQL-dependent; GDD layer adds further Oracle-specific tooling (GDSCTL, Shard Catalog, Global Services). Managed cloud tier is OCI-only. Multicloud self-hosted deployments are possible but operationally complex. Migrating away requires full schema redesign and application re-architecture
Joins
Executes fully distributed hash joins, merge joins, and lookup joins across arbitrary nodes with CockroachDB's advanced Cost-based Optimizer. Full standard SQL support for complex INNER, OUTER, LEFT, RIGHT joins across distributed tables
SQL join support with Cost-Based Optimizer. Hash, nested-loop, and merge joins with parallel query execution for analytical workloads
Intra-shard joins at Oracle native speed. Cross-shard joins require the Shard Catalog multi-shard query coordinator and incur additional network overhead. Complex multi-table joins crossing shard boundaries are slower and require careful schema and query design aligned to the sharding key
LDAP Support
NATIVE. Direct native support for external authentication systems like LDAP, Active Directory, GSSAPI, and OIDC
SUPPORTED via Oracle Internet Directory (OID) and standard LDAP. Oracle Advanced Security includes enterprise directory integration with Kerberos, RADIUS, and Oracle Wallet. Mature, enterprise-grade centralized authentication infrastructure with decades of production deployment
Inherits Oracle 26ai LDAP and enterprise directory support at the shard level. Authentication is managed per-shard via standard Oracle security mechanisms; central directory integration applies across the shard topology via the Shard Catalog's unified identity model
Migrations
Uses MOLT (Migration Off Legacy Technology) Toolkit & change data capture (CDC): MOLT handles schema conversion/verification and CDC moves data out. PostgreSQL wire protocol compatibility enables lift-and-shift; shadow mode testing
Migrating non-Oracle databases to 26ai requires Oracle SQL dialect conversion. Oracle Zero Downtime Migration (ZDM) and Database Migration Service—but only for Oracle-to-Oracle migrations
Oracle-to-Oracle migrations from legacy Oracle databases are relatively smooth. Non-Oracle migrations require sharding key design decisions upfront, a significant architectural re-design effort, before migration can begin. No equivalent to CockroachDB's MOLT toolkit for heterogeneous migration and verification
Multi-Active
YES: FULLY MULTI-ACTIVE/MULTI-REGION; read/write and handle connection requests from any node in the cluster. All nodes are equal and active; any node can accept read and write traffic simultaneously.
LIMITED. RAC provides active-active within a shared-disk cluster in a single datacenter. Cross-region active-active writes require the GDD layer. Active Data Guard standbys are read-only, not active for writes; standard Oracle 26ai DR remains active-passive across regions
LIMITED. Active-active within shard replication groups via Raft, but Shard Catalog (the cross-shard coordinator) uses Data Guard for its own HA, not Raft, creating an inconsistency in the multi-active claim at the system level
Multi-Data-Center Support
FULL. Connects geographically isolated, heterogeneous data centers (AWS, GCP, Azure, on-prem) into a single logical cluster, supported by features such as Physical Cluster Replication (PCR) and Logical Data Replication (LDR)
PARTIAL. Supported via Oracle RAC (within a datacenter) and Active Data Guard (between datacenters). Exadata Cloud@Customer for on-premises datacenter deployments. Gold/Platinum/Diamond MAA tiers provide tested multi-datacenter reference configurations with validated recovery procedures
FULL. Shards can reside across multiple datacenters, clouds, and on-premises environments. Replicas of a shard can span different cloud providers. Raft replication provides failover across availability zones and regions. Interconnects with AWS, Azure, and Google Cloud to support hybrid multi-datacenter topologies
Multi-region Functionality / Multi-region Writes
ACTIVE-ACTIVE: Read/Write from any node in any region; built-in low-latency local access patterns and Survival Goals (e.g., ALTER DATABASE...SURVIVE REGION FAILURE) commands configure fault tolerance intent
True multi‑region, multi‑active writes: any node in any region can serve reads and writes while preserving serializable consistency guarantees
Multi-region supported via Active Data Guard (active-passive standby in another region) or Global Data Services. True active-active multi-region writes require the GDD layer. Standard Oracle 26ai DR configurations remain active-passive at the region level
NOT NATIVE without GDD. Standard Oracle 26ai, even with RAC, does not support multi-region writes. Active Data Guard standbys are read-only. Must add GDD layer to achieve multi-region write capability
Multi-region NOT SUPPORTED. Shards distributed across regions; Raft replication enables failover within shard groups. Shard Catalog's own HA uses Data Guard (not Raft), creating a separate resilience dependency at the coordination layer that differs from the shard-level model
SUPPORTED via shard distribution across regions. Writes route to primary shard for a given sharding key. Cross-region write coordination is available but adds latency compared to CockroachDB's native peer-to-peer consensus across all nodes in all regions
Replication
Built-in, automatic consensus replication using the Raft protocol; data is divided into ranges and replicated across nodes
Active Data Guard (synchronous/asynchronous active-passive for DR), GoldenGate (logical replication for ETL and upgrades), and Raft replication (available within GDD layer). Standard Oracle 26ai alone uses Data Guard for cross-region replication; no built-in peer-to-peer consensus replication across regions
Three methods: Raft (low-latency within-region/AZ replication within shard groups); Active Data Guard (cross-region for Shard Catalog HA and high-latency tolerance), and separate product GoldenGate (ETL and upgrades). Raft applies within shard replication groups while Data Guard handles Shard Catalog HA, an architectural inconsistency
Required Downtime
ZERO. Online schema changes, rolling upgrades, and cluster expansion occur without taking the data platform offline
MODERATE. Rolling patching and upgrades via Oracle RAC reduce downtime for many maintenance activities. Some DDL operations and major version upgrades may require planned maintenance windows
MODERATE for shard-level operations. Adding shards, rolling updates, and online re-sharding proceed without full system downtime. Shard Catalog operations and major topology changes require coordination across all shard instances, adding operational risk and planning overhead during maintenance events
Scale
Virtually unlimited horizontal scale-out. Automatic, seamless handling of growing datasets; increase storage and throughput capacity linearly simply by adding more nodes
Scales vertically (larger, more expensive hardware) or horizontally within a datacenter via RAC on shared storage. GDD layer required for true horizontal scale-out across nodes. Exadata delivers high single-node performance. Commodity horizontal scale-out without Exadata or GDD is not a core design strength
Horizontal scale-out via sharding. Add shards online to increase storage and throughput; data rebalances automatically with minimum movement. Initial sharding key decisions require significant upfront architectural planning
Schema Changes
FULLY ONLINE & NON-BLOCKING. Online transactional schema changes (add/alter columns, indexes, constraints) run in the background without locking tables with zero downtime. Designed for always‑on services
MOSTLY ONLINE. Schema changes are theoretically possible with highly manual application multi-versioning.* Some DDL operations supported online with minimal impact; others may require locks or planned maintenance windows. Edition-based redefinition available for complex migrations
Schema changes propagate through the Shard Catalog to all shards via GDSCTL. Online for many common operations; however, coordination across the distributed shard topology adds complexity. Major schema changes carry operational risk and require careful coordination and validation across all shard instances simultaneously
Security-Privacy-Compliance
RBAC, Encryption at Rest with Customer Managed Encryption Keys (CMEK), TLS encryption in transit, IAM integrations, column-level encryption, and robust data-masking natively. Fine-grained encryption at cluster, database, table, or partition levels. Certified SOC 2 Type II and SOC 3, PCI-DSS, HIPAA, and ISO 27001-27017-27018 compliant, with ISO 42001 (Responsible, Ethical, and Safe AI Governance) pending. CockroachDB CIS Benchmarks to deploy hardened CockroachDB configurations. Comprehensive support for GDPR and DORA compliance
Oracle Advanced Security (Transparent Data Encryption, data masking, redaction), in-database SQL Firewall (26ai), quantum-resistant encryption (26ai), row/column/cell-level access controls, Oracle Vault, Label Security, and Data Safe for governance. Built-in privacy protection for AI agents and users
Inherits Oracle 26ai security features at the shard level. Data residency policies pin jurisdiction-specific data to designated shards/regions for GDPR and similar compliance. Security administration is more complex across a distributed shard fleet: each shard must be individually configured and managed
SQL Compatibility
HIGH. PostgreSQL Wire Compatible: Uses PG wire protocol; strong ANSI SQL with complex queries, joins, window functions, triggers, stored procedures, and UDFs. Supports spatial data, extensions, syntax; most apps connect with minimal or no changes
Oracle SQL Dialect. Full SQL with PL/SQL procedural extensions and Oracle-proprietary syntax. NOT PostgreSQL wire-compatible. Applications built on Oracle SQL require substantial rewrite effort migrate to other databases; existing Oracle applications connect to 26ai without changes
Oracle SQL Dialect. Inherits Oracle 26ai's complete SQL feature set via standard Oracle drivers and Global Services. Cross-shard queries use standard SQL syntax; performance depends on sharding key alignment. Not PostgreSQL wire-compatible; full Oracle SQL tooling and drivers work without modification
Storage Engine
Built on Pebble, a highly tuned, GO-based, LSM-tree key-value storage engine developed by Cockroach Labs and inspired by RocksDB specifically for distributed SQL
Oracle proprietary block-based storage engine deeply optimized for Oracle SQL and Cost-Based Optimizer. Supports row and columnar (in-memory) storage. Exadata Smart Storage adds hardware-accelerated query offload with RDMA
Same Oracle Database block-based storage engine as 26ai within each shard. The GDD sharding layer sits above standard Oracle storage — no new storage engine is introduced. Exadata Smart Storage applies within each shard for GDD on Exascale deployments, delivering hardware-accelerated offload at the shard level
Stored Procedures
SUPPORTED AND MATURE. PL/pgSQL and other languages such as Python and Perl support deep procedural logic, autonomous transactions, and complex business rule enforcement. Supports user-defined stored procedures
SUPPORTED AND MATURE. PL/SQL is Oracle's procedural language embedded in enterprise estates; supports JavaScript (26ai) and Java stored procedures. deep procedural logic, autonomous transactions, and complex business rule enforcement
SUPPORTED AND MATURE, inherited from 26ai within each shard. Cross-shard stored procedures involve the multi-shard query coordinator; complex procedural logic spanning multiple shards requires careful design to minimize cross-shard transaction overhead and maintain correctness
Transaction Performance / Isolation Levels
Optimized for OLTP with strong consistency; cross‑region transactions maintain data correctness. Optimizations like Parallel Commits drop distributed execution overhead to a single network round-trip for most transactions
Enforces strict Serializable isolation exclusively, the strongest isolation level, to ensure zero data anomalies under heavy parallel traffic, and Read Committed
Read Committed (default) and Serializable isolation. Read Committed is the default, which can expose some workloads to read anomalies without explicit isolation configuration
High single-node and RAC OLTP throughput. True Cache in 26ai reduces read latency. In-memory columnar option enables mixed OLAP/OLTP performance within a single instance or RAC cluster
Inherits Oracle isolation levels (Read Committed and Serializable) within each shard. Serializable isolation across shard boundaries is not straightforward; applications relying on serializable cross-shard guarantees require careful design and extensive testing
Strong for shard-local transactions where the workload aligns with the sharding key. Cross-shard queries and transactions incur coordination overhead through the Shard Catalog. Performance degrades when workloads cannot be cleanly partitioned by sharding key
Triggers & Deferrable Constraints
FULLY SUPPORTED. Supports triggers and deferrable constraints across all deployment models
FULLY SUPPORTED with decades of maturity. Before/after triggers, compound triggers, autonomous transactions, and deferrable constraints are all available. Oracle's trigger and constraint system is among the most comprehensive in the relational database industry
WITHIN-SHARD SUPPORT. Triggers and deferrable constraints function within a single shard. Cross-shard triggers are not natively supported. Deferrable constraint enforcement applies within a shard boundary; cross-shard deferred integrity is not natively available
Uptime SLA / Resilience
Varies by Oracle license and add-on services. When run as Oracle Autonomous Database on OCI, the stated SLA is 99.95%. A higher level of availability requires separately enabling Autonomous Data Guard. High availability is an add-on configuration, not a default
High availability via Oracle RAC (active-active within a datacenter), Active Data Guard (active-passive for DR), and Diamond-tier MAA for near-zero RPO/RTO. However, resilience requires configuring and managing multiple add-on services (RAC, Data Guard, Recovery Appliance), not a single peer-to-peer distributed engine
Oracle GDD SLA: 99.95% uptime (with Oracle Globally Distributed Autonomous Database serverless implementation on OCI). Availability is assembled from underlying Oracle components, not architected in at the database level
Raft-based replication within shards offers zero data loss, but Shard Catalog (coordination layer) relies on Oracle Data Guard, not Raft, for its own HA, creating an architectural inconsistency. Independent testing has shown CockroachDB is 5x more resilient under adverse conditions
99.999% uptime for multi-region Advanced clusters. 99.99% for single-region. SLA covers planned and unplanned downtime alike. Five nines, out of the box, backed by synchronous replication and a globally distributed active-active architecture
Five 9s availability: Survives node/disk/rack/region failures automatically via Raft consensus, with zero data loss (RPO=0). Naturally resilient to outages with granular row-level control
Vector Search
BUILT-IN NATIVE SUPPORT via VECTOR data type, scalable distributed HNSW/IVF indexing, and pgvector (the industry standard for vector similarity search). CockroachDB's C-SPANN provides distributed vector indexing (ANN) at scale; available across all tiers
BUILT-IN NATIVE SUPPORT via SQL integrates with common industry embedding models and scales with Exadata for high-throughput AI workloads
Inherits Oracle 26ai AI Vector Search within each shard. Vector queries that span shards require cross-shard coordination via the Shard Catalog. Distributed vector indexing is less mature than purpose-built distributed solutions
Writes and Query Routing
Every node is a gateway to the entirety of the database for unlimited reads and writes in any region. Any node can accept SQL queries; a Distributed Optimizer routes work to the right ranges/replicas based on locality and cost
All writes go to the primary instance or an active RAC node on shared storage. Reads can be distributed to Active Data Guard standbys or True Cache. Multi-active writes across geographic regions are not native to standard Oracle 26ai without adding the GDD layer
Shard Directors route connections to the correct shard based on the sharding key. Routing is transparent for shard-key-aligned OLTP workloads. Cross-shard DML requires Shard Catalog coordination and adds latency. Connections must use Oracle-specific Global Services rather than standard load balancers
PRICING
SIMPLE. Commercial Enterprise: Simple, straightforward pricing, plus the ability to tie data to a location to avoid egress costs. Free for single-node/dev. Free Community Tier
COMPLEX AND EXPENSIVE. CPU-based Processor or Named User Plus licensing for Enterprise Edition; options like RAC, Active Data Guard, Advanced Security, and Partitioning are separately licensed. Oracle Premier Support is priced at 20+% of net license fee. Options can be enabled accidentally, creating significant audit liability. OCI offers consumption-based pricing with OCI lock-in
HIGHLY COMPLEX. Requires Oracle Database Enterprise Edition per shard plus Shard Catalog and Director infrastructure, which multiplies licensing exposure across the shard fleet. OCI-managed Globally Distributed Autonomous Database offers consumption pricing but introduces OCI lock-in. Self-hosted multi-shard deployments dramatically increase licensing complexity and audit risk
