NewSQL & Distributed SQL Databases

Modern distributed SQL databases combining ACID with horizontal scaling: CockroachDB, TiDB, YugabyteDB, Google Spanner, Amazon Aurora, Vitess.

Database Types
7 entries
CC0 — public domain

JSON14,571 B
YAML11,449 B · −21%
TOON10,384 B · −29%

NewSQL and distributed SQL systems that keep SQL and transactional guarantees while scaling out, including CockroachDB, TiDB, YugabyteDB, Google Spanner, Amazon Aurora, Vitess and SingleStore, with their architecture, consistency model and typical uses.

Use it when

You need relational semantics and horizontal scale in one system.
You are comparing consistency and compatibility claims across distributed SQL products.

Watch out for

SQL compatibility varies; check the dialect and the features you rely on before migrating.
Cross-region transactions pay a latency cost that single-region systems do not.

The data

Databases

Name	Architecture brief	Consistency model	Scaling approach	Sql compatibility	Notable features	Use cases
CockroachDB	Distributed SQL database built on Cockroach Labs' Raft-based consensus and a custom distributed key-value store (RocksDB). Uses Google Spanner's TrueTime-inspired hybrid logical clocks for transaction ordering.	Serializable isolation (strict serializability) via MVCC and distributed transactions. Uses atomic clocks + NTP for timestamp ordering. No dirty reads.	Horizontal scaling via automatic sharding and rebalancing. Add nodes; data automatically redistributed. Geo-partitioning for data locality.	PostgreSQL wire-compatible (uses PostgreSQL syntax and protocol). Supports most PostgreSQL features, but some extensions not available.	Survive entire datacenter failures (multi-region) Automatic rebalancing and replication Survivable consensus (Raft) Schema changes without downtime Built-in geo-partitioning and locality-aware routing Change data capture (CDC) to Kafka	Global applications requiring strong consistency across regions Multi-region SaaS platforms Financial systems requiring strict ACID Applications migrating from PostgreSQL with scale needs Real-time inventory management globally
TiDB	Distributed HTAP database. Separates compute (TiDB server) from storage (TiKV). TiKV is distributed transactional key-value store (Raft consensus). TiFlash columnar store for analytics.	Snapshot isolation (SI) by default; Serializable via pessimistic transaction (TiDB 4.0+). Strong consistency within region; async cross-region replication.	Horizontal: add TiKV nodes for storage, add TiDB nodes for compute. Automatic sharding and load balancing via Placement Driver (PD) cluster.	MySQL 8.0 compatible (wire protocol and syntax). Supports transactions, secondary indexes, joins, but not all MySQL features (e.g., stored procedures).	HTAP (Hybrid Transactional/Analytical Processing): OLTP + OLAP on same data TiFlash columnar engine for real-time analytics Auto-sharding and elastic scaling Online DDL (schema changes without blocking) Distributed transactions via Percolator (2PC) Compatible with MySQL ecosystem (tools, ORMs)	OLTP with real-time analytics needs MySQL outgrowing single node Scalable SaaS applications Financial technology (fintech) E-commerce with reporting requirements
YugabyteDB	Distributed SQL database using document store (DocDB) as storage layer. DocDB is Raft-based distributed key-value store with per-shard replication.	Strong consistency via Raft consensus per shard. Serializable isolation for distributed transactions via 2PC. Reads from replicas possible with read replicas.	Horizontal via adding nodes; automatic tablet (shard) splitting and rebalancing. Tables distributed by hash or range partitioning.	PostgreSQL compatible (YSQL) and Cassandra-compatible (YCQL). YSQL supports most PostgreSQL features including extensions.	YSQL: PostgreSQL wire-compatible YCQL: Cassandra-like API for flexibility Built-in change data capture (CDC) Multi-region and active-active deployments Cloud-native (Kubernetes operators) Built-in transactional distributed counters	PostgreSQL workloads needing horizontal scale Global applications requiring strong consistency Financial services (ACID required) Real-time bidding and ad-tech IoT platforms with high write throughput
Google Spanner	Globally distributed relational database. Uses TrueTime API (GPS + atomic clocks) for globally synchronized timestamps. Storage: Paxos groups per directory; directories = contiguous key ranges.	External consistency (linearizability) via TrueTime. Strongly consistent globally. Serializability for transactions (2PC with TrueTime timestamps).	Horizontal via splitting directories (shards) and replication across regions. Automatic rebalancing. Add nodes for capacity; Spanner automatically distributes.	SQL dialect with extensions for interleaved tables, ARRAY, JSON. PostgreSQL and MySQL dialects via Cloud Spanner adapters. No foreign keys.	TrueTime globally synchronized clocks 99.999% availability SLA Automatic multi-region replication Schema changes without downtime Built-in backup/restore, point-in-time recovery Integration with BigQuery for analytics	Globally consistent financial data SaaS platforms with multi-tenant isolation Gaming leaderboards with global players Supply chain tracking worldwide Large-scale online transaction processing (OLTP)
Amazon Aurora	MySQL/PostgreSQL-compatible cloud database. Storage layer separate from compute. Uses quorum-based replication (6 copies across 3 AZs). Log-structured storage with compute caching.	Strong consistency for committed transactions. Read replicas have replication lag (typically < 100ms). ACID compliant. Isolation level configurable (REPEATABLE READ default).	Storage auto-scales from 10GB to 128TB. Compute nodes can scale vertically (instance types) or horizontally (read replicas up to 15). Separation of storage/compute.	MySQL 5.7/8.0 compatible and PostgreSQL 10+ compatible. Drop-in replacement for most apps. Some storage-specific functions differ.	Up to 5x MySQL throughput, 3x PostgreSQL throughput Storage auto-scaling to 128TB Continuous backup to S3, point-in-time recovery Serverless option (Aurora Serverless v2) Global database (cross-region read replicas) Multi-master writer (Aurora Global Database)	SaaS applications requiring MySQL/PostgreSQL compatibility High-throughput OLTP with variable load Applications needing auto-scaling storage Disaster recovery with cross-region replicas Legacy migrations to cloud with minimal changes
Vitess	Database clustering system for MySQL. Provides sharding, connection pooling, query rewriting, and topology management. Runs as separate proxy layer between app and MySQL.	Depends on MySQL transaction isolation. Vitess itself doesn't alter consistency; distributed transactions across shards via 2PC (experimental).	Horizontal via sharding. Vitess manages shard mapping, resharding, and rebalancing. Can move shards between nodes without downtime.	MySQL compatible (subset). Some queries require rewriting (joins across shards). Works with MySQL tools and clients.	Sharding and re-sharding without application changes Connection pooling (millions of connections) Query caching and result caching Online schema changes (no locking) Topology management and self-healing Works with Kubernetes (Vitess Operator)	MySQL outgrowing single instance capacity High QPS applications (YouTube-scale workloads) Need for sharding but want to keep MySQL Connection-heavy web applications Gradual migration from monolith to sharded
SingleStore	Distributed SQL database combining rowstore (OLTP) and columnstore (OLAP) in single engine. Uses distributed architecture with partitioned tables and distributed joins.	Snapshot isolation by default; Serializable for single-row operations; strict serializability with distributed transactions.	Horizontal via leaf nodes (storage) and aggregator nodes (compute). Add leaf nodes to increase capacity; aggregators route queries.	MySQL wire-compatible (80-90% compatible). Supports ANSI SQL, JSON, geospatial. Some MySQL features not supported (e.g., foreign keys).	Unified rowstore + columnstore (real-time analytics on live data) Vectorized execution engine Built-in columnstore compression Distributed joins and aggregations Pipelines for streaming ingestion Works in cloud, on-prem, hybrid	Real-time analytics on transactional data High-performance OLTP with reporting Ad-tech and marketing analytics IoT data platforms Applications requiring sub-second queries on fresh data

Fields

The shape of this dataset, read from the data itself: every column, its type and a real value. Agents can use this to plan a query without fetching the whole document.

Section	Field	Type	Example
databases	`name`	string	CockroachDB
databases	`architecture_brief`	string	Distributed SQL database built on Cockroach Lab…
databases	`consistency_model`	string	Serializable isolation (strict serializability)…
databases	`scaling_approach`	string	Horizontal scaling via automatic sharding and r…
databases	`sql_compatibility`	string	PostgreSQL wire-compatible (uses PostgreSQL syn…
databases	`notable_features`	array	[6 items]
databases	`use_cases`	array	[5 items]

Fetch the same bytes

The static files contain the same reference rows as the API, with no API rate limit. Live metadata, such as view counts, may differ. Use the API for content negotiation; use the static files for a cacheable snapshot.

curl "https://yjtoon.yunusemrevurgun.com/api/dataset/newsql-distributed-sql?format=toon"

const res = await fetch(
  "https://yjtoon.yunusemrevurgun.com/static-data/dataset/newsql-distributed-sql.toon"
);
const toon = await res.text();

Rate limit: 120 requests per minute per IP, no key and no signup. API reference →