A comparison of enterprise-grade RDBMS databases
Mission-critical applications need the reliability and consistency of a relational data store and the flexible scale, high availability, and global coverage of a distributed system.
In this paper, we compare distributed SQL database CockroachDB with Oracle Globally Distributed Database.
Lower cost of ownership
Say goodbye to costly upcharges and add-ons. CockroachDB can reduce application and ops overhead by up to 90% through automation.
Simplified operations
CockroachDB offers native scale without manual sharding, freeing up engineering hours for more productive tasks.
Cloud flexibility
Stay agile and avoid vendor lock-in. Run CockroachDB in the public cloud of your choice or in your private data center.
Uses multitenant architecture where a single container database (CDB) can host many ‘pluggable’ database instances (PDBs). These tenant PDBs may be for one or multiple separate customers all on the same Oracle instance.
Not capable of performing distributed transactions.
A logical representation of multiple independent physical databases. Each physical database is a “shard”
Requires separate sharding control plane layer for transaction management and query processing whenever >1 shards are used
Requires multiple add-on Oracle products (binaries) and increased expertise to achieve a distributed database solution
Shared-nothing distributed database
Single logical database cluster
One binary to deploy, reducing risk with a simplified application stack
Achieving high scale requires adding additional physical databases Manual sharding with tightly coupled and expensive add-ons (Oracle RAC, Data Guard, Exadata, etc)
Scale horizontally by adding additional nodes
Automatic load balancing instantly and intelligently redistributes data between existing and new nodes
High availability best achieved using expensive add-ons such as Oracle RAC, many of which only run in OCI
Requires configuring and maintaining a dedicated “Fast Recovery Area” on a separate disk group
Oracle GDD offers traditional active-active availability built in
A limited version of multi-active availability is achievable if adding Oracle Golden Gate and Active Data Guard services and running on OCI
High availability achievable only with additional Oracle services (Exadata, Data Guard, Active Data Guard)
Multi-active (active-active-active) availability with at least 3 active nodes to distribute data and perform writes.
Database can scale beyond single machines by letting all nodes in a cluster serve reads and writes
Built-in high availability and fault tolerance; set availability goals at the database, table, or row level
High availability on single cloud, multi-cloud, self-hosted, or hybrid deployments
Oracle GDD SLA: 99.95% uptime (with Oracle Globally Distributed Autonomous Database serverless implementation on OCI)
Only within single shards/instances.
ACID transactions not available when data required for that transaction is split onto on multiple shards/instances
Guaranteed
Serializable isolation by default
Offers read committed
Downtime is required for updates
Availability can be improved by adding on additional Oracle services at additional cost (RAC, Exadata, Data Guard, Oracle Fleet Patching & Provisioning, etc)
Schema changes are theoretically possible with highly manual application multi-versioning *
Downtime is required for updates
Availability can be improved by adding on additional Oracle services at additional cost (RAC, Exadata, Data Guard, Oracle Fleet Patching & Provisioning, etc)
While schema changes appear to be online, the operations still require user intervention and are not 100% autonomous
Zero downtime maintenance is built in
CockroachDB allows online schema changes and rolling upgrades
Relational databases are founded in relational algebra and deliver a highly efficient store that enforces data integrity in the database as opposed to in code.
Deliver flawless customer experiences built on accurate, always available user data.
When it comes to capturing payments at scale, data consistency and high availability are priceless.
Sell to zero (but not beyond) with always-accurate stock counts, even when shoppers have a change of cart.
*For example, version 1 of your app supports schema A, and you want to introduce schema B. First you release app version 2 that is able to work with both schemas A and B. Then with version 3 you update the schema to B. Last you deprecate support for schema A in version 4. This is one of the reasons NoSQL was invented.
Comparative claims based on publicly available information as of Q1 2024.