A Comparison of Advanced, Modern Cloud Databases

Modern Cloud Database Landscape

Cloud database technology has advanced rapidly over the past several years. Offerings now range from systems closely resembling traditional relational databases but with improved scalability, such as Amazon Aurora, to entirely novel designs leveraging custom hardware to achieve the guarantees needed for global distribution, like Google Spanner. While managing unbounded data growth remains a logistical challenge for many organizations, the available tools have never been more capable.

Tracking new entrants and understanding how they differ can be difficult. The comparison below covers several notable general-purpose options, examining their characteristics and trade-offs. No single database is a clear winner—technology choices depend heavily on organizational needs and priorities. The selection excludes the vast majority of available options, focusing on those that are most practical and interesting for building robust software.

Feature Comparison Matrix

Each column in the matrix carries specific meaning:

• Concurrent ACID: Indicates whether the database supports atomicity, consistency, isolation, and durability guarantees across multiple operations. ACID remains a powerful tool for system correctness, and true concurrent ACID has historically been difficult for distributed databases to achieve. Technically, Cosmos guarantees ACID only within a single operation.
• HA: Denotes high availability. While all databases listed are marked HA, CockroachDB, Cosmos, and Spanner lead in this area. Others tend to depend on single-node failover mechanisms.
• Horizontally Scalable: Shows whether the database scales out to additional nodes. Everything on the list except Postgres qualifies, though Aurora's scalability applies only to disk capacity—a distinction with operational caveats.
• Automatic Scalability: Differentiates databases where users manually handle data partitioning and balancing versus those where the system manages it automatically. Citus and MongoDB require explicit distribution commands and sharding keys (e.g., user_id), while Spanner automatically distributes data across available nodes and rebalances as needed. Manual distribution carries higher operational overhead and risks unbalanced sharding with disproportionately hot nodes.
• Low latency: Reflects that inter-node coordination overhead in CockroachDB, Cosmos, and Spanner makes them unsuitable where operations require roughly 1 ms latency.

CAP Considerations

The CAP theorem holds that any database can satisfy at most two of three properties: consistency, 100% availability, and partition tolerance. CAP was deliberately omitted from the comparison matrix. Eric Brewer describes the situation for Spanner:

Despite being a global distributed system, Spanner claims to be consistent and highly available... The purist answer is "no" because partitions can happen and in fact have happened at Google, and during (some) partitions, Spanner chooses C and forfeits A. It is technically a CP system. Given that Spanner always provides consistency, the real question for a claim of CA is whether or not Spanner's serious users assume its availability. If its actual availability is so high that users can ignore outages, then Spanner can justify an "effectively CA" claim.

Modern techniques can achieve CP while maintaining extraordinarily high availability—perhaps five or more 9s. This result is so compelling that contemporary databases increasingly converge on it. Every database in the comparison is CP with varying degrees of availability.

Time-Based Consistency Trade-offs

Distributed systems with sophisticated coordination logic, such as Spanner and CockroachDB, require additional time to coordinate and verify results across nodes. This makes them less suitable for low-latency operations. Measured minimum latency for a single Spanner operation is around 5 ms, with coordination details documented in the original Spanner paper. CockroachDB's FAQ explicitly states it is not an ideal choice where low-latency reads and writes are critical.

Microsoft's Cosmos documentation suggests comparable performance, citing median read and write times at 5 ms. The internal design is less transparent, but the profile aligns with other globally consistent systems.

Read Replicas, Shards, and Postgres

Amazon Aurora is a managed relational database offering an SQL interface compatible with MySQL and Postgres. It claims 5x the throughput of MySQL and 2x that of Postgres on identical hardware. What sets Aurora apart on this list is the absence of horizontal scaling at the node level; clusters resemble a traditional RDBMS setup with a primary and read replicas. Instead, Aurora scales storage, allowing tables to grow to as much as 64 TB each.

This storage-centric design restricts compute and memory for writes and consistent reads to a single vertically scaled node, but it brings benefits: data always remains colocated, so query latency stays low. It also sidesteps the risk of choosing a poor partition scheme and ending up with hot shards that require rebalancing—a mistake that is easy to make and hard to fix. For users who need extensive but not infinite scalability, Aurora may be a better fit than a system like CockroachDB or Spanner.

Citus takes a different approach. Built on Postgres, it shards and distributes individual tables across any number of nodes. It offers concepts like reference tables to enforce data locality and speed up queries. ACID guarantees apply per node, which is often sufficient given that partitioning is designed around colocation.

A notable advantage of Citus is that it is open source, running as a Postgres extension. That reduces vendor lock-in, a serious downside of several other options here, and means new Postgres features arrive at a faster pace than with Aurora. But unlike CockroachDB or Spanner, Citus requires manual sharding, which can lead to balancing problems. It is also the product of a small, young company with an unproven business model—a consideration when picking a database expected to be well-maintained a decade from now.

CockroachDB comes from Cockroach Labs, a company started by ex-Googlers with deep experience from the early days of Google's File System efforts. The design is based on the original Spanner paper, using time-based synchronization for consistency—without relying on Google's GPS and atomic clock infrastructure. It delivers serializable distributed transactions, foreign keys, and secondary indexes. Written in Go, it is open source, installable, and easy to run in development. Their documentation stands out for clarity and honesty, including an openly maintained list of known limitations.

As with Spanner, the overhead of distributed consistency makes CockroachDB a poor choice for very low latency operations; the company readily admits this. Like Citus, its future depends on a small company’s survival, which may give some organizations pause.

Cosmos, MongoDB, and Workhorse Postgres

Microsoft Cosmos DB is a far more aggressive piece of marketing, claiming to solve schema and index management entirely—

Both relational and NoSQL databases force you to deal with schema & index management, versioning and migration […] But don't worry – Cosmos DB makes this problem go away!

Schemaless design is a well-known tradeoff rather than a pure win, but Cosmos still packs a substantial feature set:

• Fast, easy geo-distribution.
• Configurable consistency, from strong serializability to eventual consistency, trading out-of-order reads for speed.
• Operation SLAs guaranteeing sub-10 ms reads and sub-15 ms indexed writes at the 99th percentile.

Distribution drags Cosmos's median read/write latency to around 5 ms, making it unsuitable for work requiring extremely low latency. It does offer ACID transactions via JavaScript stored procedures, achieving atomicity by running one script at a time and keeping rollback bookkeeping—an approach less sophisticated than the MVCC engines elsewhere, which support concurrent use.

MongoDB stores data as schemaless JSON documents but, since its debut in 2009, has attracted criticism for legitimate deficiencies in durability, security, and correctness. It has no ACID transaction support, lagging the level of sophistication of other systems here. Most others offer a strict superset of its features alongside ACID guarantees. For new projects, MongoDB is an unwise default; for existing ones, migration deserves serious thought.

Postgres needs less of a justification. It has no built-in HA, but offerings from Amazon RDS, Heroku Postgres, and the Azure Database fill that gap. Even with that limitation, Postgres is frequently still the best option because most organizations have smaller data than they assume. Actively curating data avoids bloat, allows a single vertically scaling node to suffice, and leaves a far more operable stack. Development parity between machines and production is easy—a major productivity advantage.

Practical Recommendations

For the overwhelming majority of use cases Postgres is the right starting point. Battle-tested, feature-rich, open source, and migratable across clouds and providers, it runs smoothly in development and CI. Vertical scaling goes a long way for teams that curate data and push low-fidelity information into specialized stores.

At a much larger scale—think AirBnB or Uber tier—Aurora becomes attractive. It preserves much of Postgres’s behavior while maintaining data locality and storаge scaling, at the price of losing dev/production parity and welcoming vendor lock-in. For that scale with hot workloads requiring more compute and memory than one vertically scaled node can offer, Citus is a reasonable upgrade path.

At near-Google scale, Spanner is the obvious asymptotic answer: its scalability is practically limitless, even if low latency isn’t its strength.

Write these off as informed but firsthand experience is limited to Postgres and MongoDB in production. Hidden caveats inevitably surface with more hands-on deployment. Still, most users should start on Postgres, graduate to Aurora when scale demands it, and consider Citus when the compute profile overwhelms one strong node.