YDB: A Distributed SQL Database That Scales Storage and Compute Separately

What YDB Solves and Who It Is For

YDB is a distributed SQL database built for OLTP workloads that need to scale horizontally. The README states it was designed from scratch for scalable interactive web services, where strict consistency and effective cross-row transactions were mandatory. This makes it a fit for teams running large-scale applications that have outgrown a single relational database. The project targets engineers who need a database that can survive disk, node, rack, or even datacenter outages while remaining available for reads and writes. It is not a lightweight embedded database; the minimum requirement is 8 GB of RAM on an x86 64-bit platform, and production deployments are expected to run on Ubuntu Linux. The audience is clearly developers and operators building infrastructure that cannot tolerate downtime or data inconsistency.

Architecture: Disaggregated Storage and Compute

YDB separates storage and compute layers, which is the core mechanism behind its horizontal scalability. The README explains that you can extend clusters with computation or storage resources independently. This design allows a cluster to scale storage capacity without adding compute nodes, and vice versa. The storage layer handles data redundancy and automatic recovery after failures. The compute layer executes queries and transactions. This disaggregation is what enables multitenant and serverless setups, where multiple databases share a pool of storage or compute. The README also mentions that YDB supports both row-oriented and column-oriented tables, plus persistent queues called topics for moving data. The presence of topics suggests a streaming component, though the README does not detail its mechanics.

Fault Tolerance and Consistency Model

YDB's fault tolerance model is built around three availability zones. The README states that a cluster deployed in three zones remains available for both reads and writes during a complete outage of a single zone. This is a strong guarantee, but it implies a specific deployment topology: you need at least three datacenters or failure domains. The README claims that YDB automatically restores required data redundancy after failures, with minimum latency disruptions. The consistency model is described as strict, meaning that reads reflect the latest committed write. This is a deliberate trade-off compared to databases that offer eventual consistency for lower latency. The README does not specify quorum sizes or replication factors, so you would need to consult the documentation for those details.

Deployment Options and Getting Started

To experiment with YDB, the README points to a Quick Start guide that yields a single-node cluster for functional testing and app development. For serious scenarios, such as fault tolerance testing or production workloads, you need a multi-node cluster. The README lists three deployment methods: Ansible for bare metal or virtual machines, Kubernetes for containers, and manual deployment. The exact commands are not in the README, but the documentation at ydb.tech/docs provides them. For example, the Ansible deployment guide likely involves running a playbook that initializes a cluster. The build instructions are in BUILD.md, which uses the Ya Make build system. This is not a turnkey installation; it requires familiarity with distributed system administration.

SQL and Compatibility Modes

YDB uses a custom SQL dialect called YQL for data manipulation and schema definition. This is a significant consideration: if you are coming from standard SQL, you will need to learn YQL's syntax. However, the README mentions a PostgreSQL-compatible mode for table operations and a Kafka-compatible mode for topics. This is an attempt to lower the adoption barrier. The PostgreSQL mode allows you to use familiar SQL commands for table operations, but it is not a full PostgreSQL replacement. The Kafka mode lets you interact with topics using Kafka clients. These compatibility layers are pragmatic, but they are not complete. The README does not specify the extent of compatibility, so you must verify that your specific SQL or Kafka features are supported.

Scalability and Performance Claims

The README makes bold claims: production installations with over 10000 nodes, petabytes of data, and millions of distributed transactions per second. These numbers are not independently verified by this review, and you should treat them as vendor-reported. The architecture of disaggregated storage and compute is designed to scale out horizontally, which is a real advantage over traditional relational databases that scale up. However, the README does not provide performance benchmarks or latency numbers. The claim of handling millions of transactions per second is plausible for a large distributed system, but it depends on hardware, workload, and configuration. If you are evaluating YDB, you should run your own benchmarks on a cluster that matches your target deployment.

Limitations and Cases Where YDB Is the Wrong Tool

YDB is not the right choice for small deployments. A single-node cluster is only for testing; the fault tolerance and scalability benefits require a multi-node setup. If you need a simple database for a small application, a single-node relational database like PostgreSQL or SQLite is simpler and cheaper. YDB also requires a minimum of 8 GB of RAM per node, which is heavy for development environments. The three-zone requirement for fault tolerance means you need three datacenters or at least three failure domains, which may be impractical for many organizations. Additionally, the custom YQL dialect adds a learning curve, and the PostgreSQL compatibility mode is not a full replacement. The README does not mention any limitations of the compatibility modes, so you must test them thoroughly.

Alternatives and How They Differ

The most direct alternative to YDB is CockroachDB, another distributed SQL database that offers horizontal scalability and ACID transactions. CockroachDB uses a PostgreSQL wire protocol, which means you can use standard PostgreSQL drivers and SQL syntax without a compatibility layer. YDB's approach is to offer a custom SQL dialect with a PostgreSQL-compatible mode, which may have gaps. Another alternative is TiDB, which also provides MySQL compatibility and separates storage and compute. TiDB uses a Raft-based replication for consistency, while YDB's internal replication mechanism is not described in the README. The key difference is that YDB is built from scratch with its own storage engine, while CockroachDB and TiDB are built on existing storage engines (RocksDB and TiKV respectively). This means YDB may have different performance characteristics and operational behaviors.

Maintenance, Upgrades, and License

YDB is licensed under Apache-2.0, which is permissive and allows commercial use without copyleft obligations. The project is actively maintained, with recent releases as of August 2026, including version 26.1.1.22. The release cadence appears to be roughly monthly, which suggests an active development team. However, upgrading a distributed database is not trivial. The README does not provide upgrade instructions, but you would need to plan for rolling upgrades to avoid downtime. The build system is Ya Make, which is not widely used outside Yandex-related projects, so building from source may be unfamiliar. The contributor guide and documentation for contributors are available, but the barrier to contributing is higher than for projects using CMake or other common build tools.

Editorial conclusion

Adopt YDB if you need a horizontally scalable SQL database with strong consistency and ACID transactions across multiple nodes, and if you can commit to a multi-node deployment for production workloads. Do not use it for small, single-node projects where a simpler database suffices, or if you require a single-writer primary with synchronous replication across regions. Before adoption, verify your hardware meets the 8 GB RAM minimum, confirm your operating system is supported (Ubuntu for production), and review the PostgreSQL compatibility mode's scope to ensure it covers your SQL needs. The project is actively maintained with regular releases, but its complexity demands a team comfortable with distributed systems.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes