YugabyteDB

A distributed SQL database that runs PostgreSQL’s own query layer on top of DocDB, a sharded, Raft-replicated storage engine built on RocksDB.

What it is: Relational databases,NewSQL and distributed SQL
Type: Open source
Made by: Yugabyte, Inc.
License: Apache 2.0 for the database; YugabyteDB Anywhere, the management software, is under the Polyform Free Trial License 1.0.0
Facts checked: 24 October 2026

What it is

YugabyteDB has two layers. The query layer is a fork of PostgreSQL’s: YSQL accepts Postgres clients and drivers and reuses Postgres code for parsing, planning and running queries, and a second API, YCQL, descends from Cassandra’s query language. Underneath, DocDB stores the data. Each table is split into tablets, either by a hash of the first primary-key column (the default) or by ranges of the key (ASC or DESC), and tablets split again automatically as they grow. Every tablet is a Raft group: its leader handles reads and writes, and a write commits once a majority of replicas have it, so a replication factor of 3 survives one failed node, zone or region. Two services run on each node: YB-TServer holds tablets and serves queries, and YB-Master keeps the system catalog, runs DDL and balances tablets.

Transactions use multiversion concurrency control with hybrid logical clocks, so every value is stamped with a hybrid time instead of a timestamp from one central clock. A node shuts itself down if it finds a clock more than 500 ms (--max_clock_skew_usec) away from its peers. A distributed transaction writes provisional records to every tablet it touches and a pending entry to a transaction status tablet; flipping that entry to committed makes all the writes visible at once. YSQL supports SERIALIZABLE, snapshot (REPEATABLE READ) and READ COMMITTED; new clusters on v2025.2 or later deployed with Yugabyte’s tools default to Read Committed as Postgres does, while older and manually deployed clusters still behave as snapshot by default. Tablespaces can pin a table’s replicas and leaders to chosen clouds, regions and zones, read replica clusters serve local reads, and xCluster replicates asynchronously between two clusters for disaster recovery.

The database is Apache 2.0 with no closed enterprise edition: Yugabyte opened its previously commercial features in 2019 and sells YugabyteDB Anywhere, a self-managed control plane, and YugabyteDB Aeon, a managed service, from $125 per vCPU per month (Standard) and $167 (Professional) plus storage and data transfer. Versions come in yearly long-term-support (LTS) and shorter standard-term (STS) series; v2025.2 is the current LTS and v2026.1, from June 2026, the current STS. The PostgreSQL fork was rebased from version 11 to 15 in the v2025.1 series, designed to be upgraded online.

Why teams pick it

Reuses PostgreSQL’s query layer instead of reimplementing it, so features such as stored procedures, triggers and foreign keys work as in Postgres, and Postgres drivers and ORMs connect unchanged
Writes scale out as well as reads: tablets split and rebalance across nodes, and each commits through its own Raft majority, so losing a node, zone or region needs no manual failover
Placement in SQL: tablespaces put a table’s replicas and preferred leaders in specific regions, and SPLIT INTO and SPLIT AT VALUES choose tablet layout up front
Fully Apache 2.0, including backups, encryption and read replicas, and the same database runs self-managed, on Kubernetes through Helm charts, or in Aeon

Watch out for

Postgres-compatible, not Postgres: extensions that reach into Postgres storage don’t work, some ALTER TABLE forms such as changing a primary key or column type are restricted, and every row access is a network call to DocDB, so plans and latencies differ from single-node Postgres
Default isolation depends on version and how the cluster was deployed: before v2025.2, or on manually deployed clusters, Read Committed needs the yb_enable_read_committed_isolation flag and the effective default is snapshot
Clock skew matters: conflict resolution waits on the maximum skew, nodes shut down beyond 500 ms, and Yugabyte recommends chrony or ClockBound on every node
Hash sharding spreads writes but makes range scans touch every tablet, and range sharding keeps scans local but can create a hot tablet for sequential keys, so the primary key needs to be chosen per table

Good for

Specs

Compare with alternatives →

Data model: Relational tables (YSQL) and Cassandra-style tables (YCQL), stored as DocDB documents
Query language: PostgreSQL-compatible SQL (YSQL) and a Cassandra-derived YCQL
Client protocol: PostgreSQL wire protocol for YSQL
Transactions: Any rows on any tablets and nodes
Default isolation: Read committed on new v2025.2+ clusters; snapshot on older or manually deployed ones
Consistency: Raft majority per tablet, hybrid logical clocks (500 ms maximum skew)
How it scales: Automatic: hash- or range-sharded tablets split and rebalance
Replication: Raft per tablet, replication factor 3 typical; xCluster for asynchronous copies
Multi-region: Tablespaces pin replicas and leaders per region; read replica clusters; xCluster for disaster recovery
Storage engine: DocDB on a customized RocksDB (LSM) per tablet
Written in: C++ (DocDB), under a fork of PostgreSQL’s query layer
Ways to run it: Self-hosted, Helm charts on Kubernetes, YugabyteDB Anywhere, or YugabyteDB Aeon
Pricing model: Aeon: per vCPU per month ($125 Standard, $167 Professional), plus storage and data transfer

Alternatives

What all relational databases have in common →Compare side by side →

CockroachDBCommercialAlso good for serializable transactions across keys and sql past one server and 1 moreA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.

TiDBOpen sourceAlso good for sql past one serverA distributed SQL database that speaks the MySQL protocol, stores rows in TiKV, a Raft-replicated key-value store, and can keep a columnar copy in TiFlash for analytics on live data.

CitusOpen sourceAlso good for sql past one serverA PostgreSQL extension that shards tables across a cluster of ordinary Postgres servers, sending each query to the one shard it needs or to all shards in parallel.

PostgreSQLOpen sourceAlso good for serializable transactions across keysThe open-source relational database that most new projects start on, extensible enough to grow into many niches.+2 Citus, Omnigres

NeonCommercialServerless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.

FoundationDBOpen sourceAlso good for serializable transactions across keysAn ordered, distributed key-value store with strictly serializable ACID transactions across the whole cluster, built as a small core that other databases are layered on.

DocumentDBOpen sourceA MongoDB-compatible document database built as PostgreSQL extensions plus a gateway, so MongoDB drivers and tools talk to Postgres underneath.

How it fits with other technologies

What YugabyteDB uses

Choosing hash or range sharding, and pinning replicas to regions · sql

-- hash on customer_id spreads writes over 12 tablets; rows within a customer are sorted by time
CREATE TABLE orders (
  customer_id bigint,
  placed_at   timestamptz,
  total       numeric,
  PRIMARY KEY ((customer_id) HASH, placed_at DESC)
) SPLIT INTO 12 TABLETS;

-- range-sharded: scans by id stay on neighbouring tablets; 3 split points make 4 tablets
CREATE TABLE invoices (id bigint, body jsonb, PRIMARY KEY (id ASC))
  SPLIT AT VALUES ((1000000), (2000000), (3000000));

-- three replicas in three regions, leaders preferred in us-east-1
CREATE TABLESPACE us_tablespace WITH (replica_placement='{"num_replicas": 3, "placement_blocks": [
  {"cloud":"aws","region":"us-east-1","zone":"us-east-1b","min_num_replicas":1,"leader_preference":1},
  {"cloud":"aws","region":"us-east-2","zone":"us-east-2a","min_num_replicas":1,"leader_preference":2},
  {"cloud":"aws","region":"us-west-1","zone":"us-west-1a","min_num_replicas":1}]}');

CREATE TABLE us_customers (id bigint PRIMARY KEY, email text) TABLESPACE us_tablespace;

DocDB: the storage layer#

DocDB is the part of YugabyteDB that owns transactions, sharding, replication and persistence. It is written in C++ and built on a heavily customized RocksDB, an LSM-tree key-value store: each tablet has its own RocksDB instance, writes land in a memtable, are flushed to sorted SST files, and are merged by compaction, which also drops versions no transaction can still read. Because Raft already keeps a write-ahead log for every tablet, DocDB turns RocksDB’s own WAL off and tracks which Raft entries have been flushed, so the Raft log can be trimmed and replayed after a crash. All RocksDB instances on a server share one block cache, which resists being flushed out by long scans, and one memory limit for memtables.

Each row is a document. Its key is the primary key, encoded so that ordering works: a 16-bit hash of the hash columns (if any), then the hash columns, then the range columns, and finally a hybrid timestamp sorted newest first. Other columns are subdocuments keyed by column ID, and nested collections in YCQL become nested maps. Since v2.20 new YSQL clusters store rows packed, one key-value pair per row, and an update to a few columns adds small per-column entries until compaction folds them back. Deletes write a single tombstone, and range queries skip SST files using the minimum and maximum key components stored with each file.

Uncommitted writes don’t go into the main store. Each tablet keeps a second RocksDB instance, IntentsDB, for provisional records, next to RegularDB for committed data. When the transaction status tablet marks a transaction committed and assigns its commit time, the provisional records are rewritten into RegularDB with that hybrid time as their MVCC version; if the coordinator stops heartbeating, they expire and the transaction is aborted. Keeping intents separate makes aborted transactions cheap to clean up and lets each store use its own flush and compaction settings.

See it in a real stack

No architecture uses YugabyteDB yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2016–2026

Kannan Muthukkaruppan, Karthik Ranganathan and Mikhail Bautin had built and run Apache Cassandra and HBase at Facebook, for workloads such as Messenger. In February 2016 they started Yugabyte to build one database with the scale and resilience of those NoSQL systems and the transactions and SQL of a relational one. Its first production API, YCQL, was derived from Cassandra’s query language; a PostgreSQL-compatible one came next.

The team first wrote a Postgres-compatible layer from scratch, and after about five months threw it away and forked PostgreSQL’s query layer instead, putting it on top of their own distributed storage. Version 2.0, in September 2019, made that API, YSQL, production-ready after Jepsen testing. Two months earlier, with version 1.3, Yugabyte had moved every feature under Apache 2.0 and dropped its closed enterprise edition, against the trend of database companies tightening their licences. In 2024 it began rebasing its Postgres fork from version 11 to 15, released in the v2025.1 series, and in 2026 it added AMP, a scale-to-zero, multitenant Postgres tier aimed at AI agents.

Why it’s built this way

Reuse PostgreSQL’s query layer instead of rewriting it: A from-scratch layer would have to catch up with decades of Postgres features and tests one by one. Reusing the code brought features, documentation and regression tests at once, and Yugabyte called it one of its best design decisions, at the cost of extensions that touch Postgres storage.
Raft per tablet, with no RocksDB write-ahead log: Each tablet replicates through its own Raft log, which already records every write in order. A second log inside RocksDB would only add writes, so DocDB disables it and uses the Raft log for recovery.
Hybrid logical clocks instead of a central timestamp service or atomic clocks: Ordinary cloud machines have no TrueTime. A hybrid clock of physical time plus a logical counter, exchanged on every RPC, keeps timestamps increasing without a single timestamp server, in exchange for a bound on clock skew.
All features open source, money from managed services: The founders argued that licences like AGPL or BSL slow adoption without stopping cloud providers, and that companies pay for running the database rather than for features withheld from it.

Timeline

2016
Yugabyte founded by three former Facebook engineers
2019
Version 1.3 moves everything to Apache 2.0 in July; 2.0 makes YSQL production-ready in September
2020
Yugabyte explains why it rebuilt YSQL on PostgreSQL’s own query layer
2024
Work starts on rebasing the Postgres fork from version 11 to 15
2025
v2025.1 series ships PostgreSQL 15 compatibility; v2025.2 becomes the LTS
2026
v2026.1 adds vector indexing and the AMP serverless tier

Sources21 · facts checked 24 October 2026

Improve this page on GitHub