Oracle is a premier database provider, delivering solutions that cover most every possible permutation of SQL database configuration you can imagine. While complicated and expensive, Oracle has always delivered on its promises… until now.

Distributed SQL is growing in popularity, and with the entry of Amazon DSQL into the market the sector itself is being validated as it emerges from niche offering to full-on database option. As we’ll see below, Oracle’s offering leaves a lot to be desired.

Comparing Oracle with CockroachDB is like comparing apples to oranges. They’re both databases, but that’s where the similarities end. Oracle can be described as the standard trope: “jack of all trades, master of none.” It’s a high-performing database designed for every use case, and as a result delivers a complex interplay of products and add-ons that’s difficult to manage, costly, and doesn’t come close to the promises of distributed SQL.

CockroachDB, on the other hand, does deliver on everything distributed SQL has to offer. It’s built from the ground up to be a cloud-native and run anywhere, Postgres-compatible, distributed database with a simple declarative language for geo-data placement to allow for both compliance and performance use cases.

Here’s an important example of the distributed database design gaps in Oracle GDD: After extensive Performance under Adversity testing, it’s clear that CockroachDB is 5x more resilient than Oracle GDD, Oracle’s distributed database, as measured by outage scenarios under adverse conditions. This testing was completed with the free version of Oracle 23ai self-hosted.

Why does this matter? Because enterprises need distributed databases to power global scale, ensure availability during outages, and deliver consistent performance wherever their customers are located. The database decision impacts a lot more than infrastructure: It determines business resilience, cost efficiency, and the ability to innovate quickly without being constrained by complexity or compliance barriers.

While Oracle GDD layers distributed capabilities onto a legacy architecture – making scale, availability, and consistency complex and costly – CockroachDB was purpose-built for these demands from the ground up with a simplified architecture. It delivers seamless global performance, automated fault tolerance, strong ACID consistency, and straightforward operations, giving enterprises a platform that strengthens their competitive position instead of holding it back.

This article explores several of these key differences between CockroachDB and Oracle GDD in depth.

What is Oracle GDD?

Oracle released Oracle Globally Distributed Database (GDD) in March of 2024.

Oracle GDD is Oracle’s answer to distributed SQL. It’s designed to be a horizontally scalable database that presents as a single logical database while enabling data residency requirements. However, as we’ll demonstrate in this post, GDD’s complexity limits its real-world possibilities – while failing to accomplish the goals defined by the distributed SQL market.

Oracle’s website defines GDD as having the following characteristics:

Always-on architecture

Performance and scale

Address data residency requirements

Simple to use and manage

Deploy in the cloud and your data center

In fact, all Oracle has done with GDD is add a sharding layer on top of non-distributed SQL databases; these databases don’t know anything about each other and depend on the sharding layer to know where to put data or retrieve it. Meanwhile, the sharding layer is a separate database that tracks the shards, but this separate sharding database layer doesn’t support active-active Raft replication and so itself isn’t always-on resilient.

GDD is clearly *not *a native distributed SQL solution: It’s a wrapper around centralized Oracle databases that’s meant to mimic the capabilities of distributed SQL – and does a poor job at doing so.

Oracle GDD Limitations

Let’s delve into the many operational bottlenecks that Oracle GDD users encounter.

Oracle GDD’s architecture is complicated

Oracle GDD’s architecture relies on multiple interdependent components including shard directors, a shard catalog, and separate databases, that increase operational complexity and limit resilience.

For self-hosted options, CockroachDB has a single binary that runs on any cloud on on premise and does everything needed to deliver a distributed SQL database. CockroachDB Cloud offers the simplicity of a managed service, with tiers that deliver either serverless or dedicated infrastructure and runs on our cloud infrastructure or yours (BYOC), with options to grow and easily migrate between tiers.

Oracle, on the other hand, has multiple products that are required to create and run Oracle GDD. You have to run Oracle databases for your application, with additional databases required at a sharding coordination layer. Those databases are at the sharding layer, meaning the Shard Catalog and Shard Director don’t support Raft active-active, so for high-availability of those components you need to run Oracle Data Guard.

Adding to the inconvenience is that Oracle’s fully managed service, Globally Distributed Autonomous Database, is only available on Oracle Cloud Infrastructure (OCI) – and only on a handful of regions.

The Oracle GDD multi-layer architecture leads to further frustrations:

Oracle’s complicated architecture presents limitations

Oracle GDD has some fundamental weaknesses, beyond the very real problem of complexity and deep product knowledge necessary to configure GDD correctly.

There are ACID limitations on cross-shard transactions (page 191 in their docs). In particular, the MERGE statement is not supported when the MERGE statement requires the modification of multiple shards. As an example, you have a sharded table called “customers,” and the sharding key is a field called “home_region” (us-east, us-west). You can’t do a basic merge statement on the table.

There’s also no indexing across shards. Coordinating reads across multiple shards is hard! That’s because supporting global index structures requires the system to know about locality and distribution at multiple levels of the tech stack – which Oracle can’t do.

Returning to our above example, imagine you wanted to search the customers table by last_name and you wanted to index the last_name field. Oracle will let you create an index inside of each shard (a “local index”) but not a global index on the last_name field. That means, you can’t do an efficient search across the whole database on the index.

For similar reasons, there is limited support for cross-shard complex reads, and it’s hard to do complex joins, global indexes, etc...

Finally when it comes to complicated architecture, there are two main forms of sharding in Oracle GDD – system managed and user defined. Choose carefully! It’s very difficult to change between these once configured even though they serve very different purposes. If you need geo-placement of data, you must go with user-defined partitioning… but user-defined partitioning doesn’t support Raft active-active resilience. If you want Raft for multi-active resilience, you have to choose system-managed sharding… but then you’re limited on geo-data placement.

GDD is a patchwork of different options because there is no singular option that works for all use cases, and even the use cases Oracle can support are very limited. For example, the GDD Shard Catalog is an HA instance and doesn’t use Raft. If the Shard Catalog goes down, data on Shards could get stale. So while the underlying GDD shards (sometimes) use Raft, the whole system doesn’t and suffers survivability limitations as a result. This is the root of the results we saw in our Performance under Adversity testing where CockroachDB was 5x more resilient than Oracle GDD on 23ai free version, self-hosted.

Multi-region data placement limitations

Oracle’s multi-region data placement capabilities are built on a combination of replication, partitioning, and manual sharding, rather than a unified, declarative model.

CockroachDB delivers best-in-class declarative locality controls, enabling developers to directly manage data placement using intuitive SQL syntax such as REGIONAL BY ROW, REGIONAL BY TABLE and LOCALITY GLOBAL etc... This streamlined approach simplifies multi-region deployments by automating geo-partitioning and replication strategies, ensuring that data remains close to its users and reducing cross-region latency.

Oracle provides no native equivalent to CockroachDB’s REGIONAL BY ROW or super region constructs. Multi-region deployments require careful data modeling, infrastructure support, and often third-party tooling.

Replication factor limitations

In consensus replication, the number of failures that can be tolerated is equal to (Replication factor - 1)/2. For example, with 3x replication, one failure can be tolerated; with 5x replication, two failures, and so on.

Oracle GDD is limited to a replication factor of 3, where CockroachDB doesn’t have such a limitation. This means that Oracle can’t survive two simultaneous failures as it would be able if it supported a replication factor of five.

A replication factor of five is important for a very common real-world use case – that of regular maintenance. For example, upgrading Linux on the server may require that server to be taken out of the cluster for tens of minutes, or even half-an-hour. Therefore, performing this Linux upgrade across all nodes in a cluster can take an entire day.

During that upgrade, you have two choices:

Allow the cluster to up-replicate, which requires a LOT of rebalancing, perhaps affecting the workload. 1.

Take a risk and hope that while the cluster is under maintenance nothing else fails.

A database with a replication factor of three can only survive one failure – and that “failure” is being accounted for by the upgrade. A second failure would bring the application down. Running with a replication factor of five is a cost effective way of ensuring that your cluster can survive an additional node failure, even during regularly scheduled online maintenance.

Cloud limitations

There are complicated OCI dependencies that prevent a true multi-cloud configuration (for example, as mandated by DORA). CockroachDB runs on AWS, Azure, or GCP and can run across-clouds, on-premise, or hybrid configurations with ease.

Online Schema Changes

From Oracle docs: “The sharding key should be very stable; its value should almost never change.” This is in contrast to CockroachDB’s support for online schema changes, where schema changes can occur with no downtime.

CockroachDB: A higher standard

CockroachDB was written from the ground up to support Postgres-compatible distributed SQL. Oracle was written for legacy applications, when scaling meant getting a larger server and resilience meant acceptable downtime.

CockroachDB supports SQL guarantees (strong consistency, ACID) across a distributed framework. We use the Raft protocol to enforce ACID on writes, with every node able to both read and write to the database. We have a distribution-aware query engine that optimizes SQL execution across cluster nodes. Oracle doesn’t live up to these standards in many situations, as we’ve seen above.

That’s why this choice matters. Enterprises need more than infrastructure: they need resilience, cost efficiency, global performance, and the ability to innovate without being constrained by complexity or compliance barriers. CockroachDB is a modern database built for this reality.

For a more in-depth comparison, including a summary comparison table, head over to our Oracle comparison page and download the comparison white paper.

Ready to learn more about how CockroachDB outperforms Oracle? Talk to an expert today.

David Bressler is Staff Product Marketer for Cockroach Labs.