{ "api": "YAML JSON TOON Database", "version": "1.0.0", "format": "json", "dataset": { "id": 357, "slug": "newsql-distributed-sql", "title": "NewSQL & Distributed SQL Databases", "description": "Modern distributed SQL databases combining ACID with horizontal scaling: CockroachDB, TiDB, YugabyteDB, Google Spanner, Amazon Aurora, Vitess.", "category": "Database Types", "category_slug": "database-types", "tags": "database,newsql,distributed-sql,cockroachdb,spanner,aurora", "view_count": 2, "created_at": 1781275786, "updated_at": 1781275786 }, "data": { "databases": [ { "name": "CockroachDB", "architecture_brief": "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.", "consistency_model": "Serializable isolation (strict serializability) via MVCC and distributed transactions. Uses atomic clocks + NTP for timestamp ordering. No dirty reads.", "scaling_approach": "Horizontal scaling via automatic sharding and rebalancing. Add nodes; data automatically redistributed. Geo-partitioning for data locality.", "sql_compatibility": "PostgreSQL wire-compatible (uses PostgreSQL syntax and protocol). Supports most PostgreSQL features, but some extensions not available.", "notable_features": [ "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" ], "use_cases": [ "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" ] }, { "name": "TiDB", "architecture_brief": "Distributed HTAP database. Separates compute (TiDB server) from storage (TiKV). TiKV is distributed transactional key-value store (Raft consensus). TiFlash columnar store for analytics.", "consistency_model": "Snapshot isolation (SI) by default; Serializable via pessimistic transaction (TiDB 4.0+). Strong consistency within region; async cross-region replication.", "scaling_approach": "Horizontal: add TiKV nodes for storage, add TiDB nodes for compute. Automatic sharding and load balancing via Placement Driver (PD) cluster.", "sql_compatibility": "MySQL 8.0 compatible (wire protocol and syntax). Supports transactions, secondary indexes, joins, but not all MySQL features (e.g., stored procedures).", "notable_features": [ "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)" ], "use_cases": [ "OLTP with real-time analytics needs", "MySQL outgrowing single node", "Scalable SaaS applications", "Financial technology (fintech)", "E-commerce with reporting requirements" ] }, { "name": "YugabyteDB", "architecture_brief": "Distributed SQL database using document store (DocDB) as storage layer. DocDB is Raft-based distributed key-value store with per-shard replication.", "consistency_model": "Strong consistency via Raft consensus per shard. Serializable isolation for distributed transactions via 2PC. Reads from replicas possible with read replicas.", "scaling_approach": "Horizontal via adding nodes; automatic tablet (shard) splitting and rebalancing. Tables distributed by hash or range partitioning.", "sql_compatibility": "PostgreSQL compatible (YSQL) and Cassandra-compatible (YCQL). YSQL supports most PostgreSQL features including extensions.", "notable_features": [ "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" ], "use_cases": [ "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" ] }, { "name": "Google Spanner", "architecture_brief": "Globally distributed relational database. Uses TrueTime API (GPS + atomic clocks) for globally synchronized timestamps. Storage: Paxos groups per directory; directories = contiguous key ranges.", "consistency_model": "External consistency (linearizability) via TrueTime. Strongly consistent globally. Serializability for transactions (2PC with TrueTime timestamps).", "scaling_approach": "Horizontal via splitting directories (shards) and replication across regions. Automatic rebalancing. Add nodes for capacity; Spanner automatically distributes.", "sql_compatibility": "SQL dialect with extensions for interleaved tables, ARRAY, JSON. PostgreSQL and MySQL dialects via Cloud Spanner adapters. No foreign keys.", "notable_features": [ "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" ], "use_cases": [ "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)" ] }, { "name": "Amazon Aurora", "architecture_brief": "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.", "consistency_model": "Strong consistency for committed transactions. Read replicas have replication lag (typically < 100ms). ACID compliant. Isolation level configurable (REPEATABLE READ default).", "scaling_approach": "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.", "sql_compatibility": "MySQL 5.7\/8.0 compatible and PostgreSQL 10+ compatible. Drop-in replacement for most apps. Some storage-specific functions differ.", "notable_features": [ "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)" ], "use_cases": [ "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" ] }, { "name": "Vitess", "architecture_brief": "Database clustering system for MySQL. Provides sharding, connection pooling, query rewriting, and topology management. Runs as separate proxy layer between app and MySQL.", "consistency_model": "Depends on MySQL transaction isolation. Vitess itself doesn't alter consistency; distributed transactions across shards via 2PC (experimental).", "scaling_approach": "Horizontal via sharding. Vitess manages shard mapping, resharding, and rebalancing. Can move shards between nodes without downtime.", "sql_compatibility": "MySQL compatible (subset). Some queries require rewriting (joins across shards). Works with MySQL tools and clients.", "notable_features": [ "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)" ], "use_cases": [ "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" ] }, { "name": "SingleStore", "architecture_brief": "Distributed SQL database combining rowstore (OLTP) and columnstore (OLAP) in single engine. Uses distributed architecture with partitioned tables and distributed joins.", "consistency_model": "Snapshot isolation by default; Serializable for single-row operations; strict serializability with distributed transactions.", "scaling_approach": "Horizontal via leaf nodes (storage) and aggregator nodes (compute). Add leaf nodes to increase capacity; aggregators route queries.", "sql_compatibility": "MySQL wire-compatible (80-90% compatible). Supports ANSI SQL, JSON, geospatial. Some MySQL features not supported (e.g., foreign keys).", "notable_features": [ "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" ], "use_cases": [ "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" ] } ] } }