YDB: a distributed SQL database with row and column tables in one cluster

The workload YDB was built for

YDB targets interactive web services where the data does not fit comfortably on one machine and where the application cannot tolerate reading stale rows. The README is explicit about the design motivation: scalability, strict consistency, and cross-row transactions were treated as requirements, not features added later. That combination is what separates it from a plain key-value store and from a single-node relational database.

The project's own framing is that it was built by people with backgrounds in databases, distributed systems, a NoSQL database, and a MapReduce system at a large search engine. That history shows up in the data model. One cluster offers row-oriented tables for transactional workloads and column-oriented tables for analytical ones, plus persistent queues (topics) for moving data between components. A team that would otherwise run a transactional database, an analytical store, and a message broker can point all three at one system.

The intended user is an infrastructure or backend team running a service with unpredictable growth. The README states that current production installations exceed 10000 nodes and handle millions of distributed transactions per second, which is the scale the design assumes. If your dataset fits on one server, the operational cost of a distributed cluster is not repaid.

Storage and compute scale independently, and that shapes operations

The architecture described in the README separates the storage layer from the compute layer and lets each scale horizontally on its own. This is the detail that matters most when you plan capacity. Adding storage nodes and adding compute nodes are different operations with different effects, and the README presents this as a deliberate contrast with traditional relational databases, which scale out as a unit.

Fault tolerance is expressed in terms of what fails. The README says a cluster can be deployed across three availability zones, and that during a complete outage of a single zone the cluster remains available for both reads and writes. Recovery is automatic: after a disk, node, rack, or datacenter failure, the documentation states that YDB stays available and restores the required data redundancy without operator intervention. Regions and availability zones are covered in the concepts documentation rather than the README.

Multitenancy is a first-class option. A single cluster can host several databases that share one pool of storage while running on separate compute nodes, or several serverless databases that share a pool of compute. For a platform team this changes the unit of provisioning from cluster to database, which is a real difference from deploying one database instance per team.

What the README does not describe is the failure behaviour you would want before an incident: how long a zone failover takes, how the cluster behaves when two zones are unavailable, and what operational signals indicate that redundancy has not yet been restored. Those answers live in the linked documentation, and a team evaluating YDB should read them there before trusting the one-line availability claim.

Installing YDB and running a first query

The README does not contain install commands. It points to the Quick Start guide in the documentation, which the README describes as yielding a single-node cluster suitable for functional testing and app development. That is the path to take for a first look; the README is explicit that more serious scenarios need a multi-node cluster deployed with Ansible for bare metal or virtual machines, or Kubernetes for containers.

Because the README gives no command lines, the only instruction that can be reproduced faithfully here is how to obtain the server and client binaries from source. BUILD.md is the file the README names for building the server (ydbd) and the client (ydb), and it also links the documentation for the Ya Make build system. The repository root contains the ya launcher and its configuration, which is the entry point for that build system.

./ya make

Running the Ya Make launcher from the repository root is the build step the repository layout implies; BUILD.md is where the exact targets and prerequisites are documented, and it should be read before running anything. Expect a C++ build with the usual toolchain and time cost, not a package install.

Client access is through the ydb binary and through SDKs. The README does not list supported languages or give a connection example, so there is no honest snippet to show for opening a session or issuing a statement. A reader should treat the SDK list and the connection parameters as things to confirm in the documentation, not to guess from the README. The same applies to ports and environment variables: none appear in the README, and inventing them would be worse than leaving them out.

Where YDB is the wrong choice

The clearest limitation is stated by the project itself. The Quick Start cluster is a single node, and the README scopes it to functional testing, app development, and similar tasks. It is not a production deployment. Anyone who evaluates YDB by running the quick start and then puts that same setup in front of users has skipped the part of the documentation that matters.

Production means Ansible or Kubernetes, and that means a real operational commitment: configuration management, monitoring, capacity planning for two independently scaled layers, and a release cadence to follow. The minimal system requirement in the README is an x86 64-bit platform with at least 8 GB of RAM, and production environments in practice run 64-bit x86 under Ubuntu Linux. MacOS and Windows are described as development and testing targets, tested against their latest versions, not as production platforms. A team standardized on ARM servers or on Windows in production is outside what the README claims.

There is also a modelling cost. YDB uses its own SQL dialect, YQL, for data manipulation and schema definition. The README presents PostgreSQL-compatible mode for table operations and Kafka-compatible mode for topics, which softens migration for some workloads, but compatibility modes are not the same as running the original engine. If your application depends on PostgreSQL-specific behaviour beyond what the compatibility documentation covers, that gap is yours to find.

Finally, consider the shape of the problem. If you need a single-node relational database with a large ecosystem of extensions, or you need analytical queries over data already sitting in object storage, YDB's distributed transaction machinery is overhead you will pay for and not use.

YDB compared with YugabyteDB

The comparison people search for is YDB against YugabyteDB, and the two take different routes to a similar goal. Both are distributed SQL databases with horizontal scaling and ACID transactions. The difference visible in the YDB README is the data model and the deployment surface.

YDB puts row-oriented and column-oriented tables in the same system, alongside persistent queues, and exposes all of it through YQL with PostgreSQL-compatible and Kafka-compatible modes layered on top. YugabyteDB is built around PostgreSQL compatibility as the primary interface, which means existing PostgreSQL tooling and drivers are the expected path rather than a compatibility mode. If your team's skills and migration plan are PostgreSQL-shaped, that is a meaningful difference in approach, not a detail.

The second difference is deployment. YDB's README names Ansible for bare metal or virtual machines and Kubernetes for containers, and describes multitenant and serverless configurations within one cluster. That is a platform-oriented story: one cluster serving many databases. Teams that want a database they deploy per application, with less shared infrastructure to reason about, are looking at a different operational model.

Neither approach is strictly better. YDB's breadth (transactions, analytics, queues, multitenancy) means more concepts to learn before the first production deploy. YugabyteDB's narrower PostgreSQL-first surface means fewer new concepts but less room to consolidate a queue or an analytical store into the same cluster.

Maintenance, releases, and the Apache-2.0 licence

YDB is licensed under Apache-2.0, which permits commercial use, modification, and redistribution under the terms of that licence. This is a permissive licence, so the usual copyleft obligations do not apply to your application code. That is a general property of Apache-2.0 and not legal advice; if you redistribute YDB itself or modify it, read the licence text and, where it matters, talk to a lawyer.

Upgrade cost is the practical concern. The release history shows a steady cadence: 25.4.1.15 on 2026-06-05, 26.1.1.20 on 2026-07-02, and 26.1.1.22 on 2026-08-04, with the repository's last push on 2026-08-04. Releases arrive roughly monthly, and the version scheme mixes a year-based major number with build numbers. A team running YDB in production should expect to read release notes before each upgrade and to test on a staging cluster, because the README does not document rollback and the release notes give no compatibility guarantees between releases.

The repository is not archived and the last push is recent, so the project is under development. That cuts both ways: fixes arrive, and so does change. The cost of adoption is not the licence or the download, it is the ongoing attention a distributed database demands, and the release cadence sets how often that attention is required.

Editorial conclusion

Adopt YDB if you need cross-row ACID transactions over a cluster that must survive a zone outage and you can commit to running a multi-node deployment with Ansible or Kubernetes. Do not adopt it if you only need a single-node relational database for a small application: the quick start cluster is documented as suitable for functional testing and app development, not production. Before committing, verify three things against the documentation: the exact Ansible or Kubernetes deployment path for your environment, whether your workload needs row-oriented or column-oriented tables, and whether your client language is covered by the available SDKs. The repository's last push was on 2026-08-04, so the codebase is moving and you should expect to track releases rather than pin one build for years.

Frequently asked questions

Official sources

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