YDB matters not only because of its origin inside Yandex, but because it combines distributed SQL with a platform view of multi-tenancy, scaling, and operations.
In real projects, this chapter helps you reason about tenant isolation, quotas, transaction scope, and batched writes as properties of the whole platform rather than local optimizations for one team.
In interviews and architecture discussions, it is most useful when you need to justify YDB through fault tolerance, noisy-neighbor control, and predictable behavior at scale.
Practical value of this chapter
Multi-tenant boundaries
Design tenant isolation and quota strategy so noisy neighbors do not violate platform-level SLA.
Transactional contours
Define transaction scope and batching model for distributed SQL execution behavior.
Storage/compute elasticity
Tie scaling strategy to workload profile and expected traffic spikes.
Interview rationale
Justify YDB through fault tolerance, multi-tenant governance, and operational predictability requirements.
Decision frame and editorial focus
Chapter focus
YDB distributed SQL architecture, multi-tenancy, and scaling
Workload profile
The focus is transactional SQL at horizontal and often regional scale where one classic node no longer scales cleanly.
Good fit
Distributed SQL is justified when strong guarantees matter more than simplicity and the team accepts latency, coordination, and operations cost.
Boundary and risk
Key risks are hot keys, cross-region transactions, consensus cost, rebalancing, and the illusion of free sharding.
Connect next
Always validate the choice against a PostgreSQL/MySQL baseline, distributed transactions, and multi-region architecture.
Source
Wikipedia: YDB
YDB's path from KiWi and KiKiMR to the public DBMS: release milestones and the architecture frame at a glance.
Official docs
YDB Docs: Architecture
The primary source on architecture: shared-nothing design, YDB tablets, automatic sharding, distributed transactions, and the storage layer.
YDB (Yet another DataBase) is a distributed SQL database with ACID transactions, automatic sharding, and shared-nothing architecture. You reach for it once a single node stops holding the load and application-side sharding turns into a source of bugs. YDB takes the partitioning and coordination onto itself — but you pay for that with key design and the operational cost of running a distributed cluster.
History and context
Development starts in Yandex internal infrastructure
Inside Yandex, the KiWi distributed key-value layer begins — the foundation that scalable services will later grow on.
Transition toward distributed SQL
KiKiMR is built around tablets and the actor model — the skeleton that later becomes YDB's core architecture.
Broad production usage inside Yandex
YDB-style architecture carries high-load services across the Yandex ecosystem — a trial by fire before it goes public.
Public open-source release
YDB goes public as an open-source distributed SQL DBMS with ACID guarantees and automatic sharding — now you can put it in your own stack.
24.3 server branch stabilization
The 24.3 branch accumulates fixes and hardens stability to the point where it is safe to keep in production clusters.
New 25.x minor line
The 25.x line keeps moving: new SQL capabilities, performance tuning, and smoother day-to-day operations.
Core architecture elements
Tablets and auto-sharding
Table data lives in YDB tablets: as load grows they split and move between nodes on their own, so repartitioning never becomes a manual weekend operation.
Serializable transactions
Isolation is serializable and concurrency is optimistic: conflicting operations do not block each other up front, but on a collision the transaction rolls back — and your code has to handle that.
Row + column tables
One platform holds row tables for the OLTP contour and column tables for analytics right next to them, which removes some of the copying into a separate system.
Disaggregated compute/storage
Compute is separated from storage, so capacity and load scale independently; the cluster spreads across multiple availability zones and survives the loss of any one of them.
Data model and transaction contour
The interactive section below shows how row and column tables, automatic sharding, indexes, and distributed transactions coexist in YDB — and where the boundaries between them run.
YDB data model: tables, shards, and transactions
YDB combines a relational model with automatic sharding and distributed transactions for high-load systems.
Why YDB is more than a typical SQL database
- Every table requires a primary key, and data is physically distributed across shard tablets.
- Both row-oriented and column-oriented tables are available for OLTP and OLAP profiles.
- Distributed transactions with serializable isolation and OCC are built in.
- Topics, CDC, and asynchronous replication let teams build integrated data pipelines.
Row-oriented tables
Core table type for transactional workloads: primary key is mandatory and rows are sorted by key.
Key elements
Typical use cases
- User/account state
- Orders/payments
- Transactional APIs
Example
CREATE TABLE orders (
tenant_id Uint64,
order_id Uint64,
status Utf8,
amount Uint64,
PRIMARY KEY (tenant_id, order_id)
);YDB architecture by layer
Here you can see how a request travels top to bottom: client access, SQL and transaction processing, tablets and shards, distributed storage, and fault-tolerance mechanics.
System view
Data model
Operational trade-offs
Read and write paths through components
A single diagram brings together the write and read paths and shows how requests move through discovery, the transaction coordinator, shards, and replicated storage. This is exactly where you can see cross-shard coordination add an extra step.
Read/Write Path Explorer
Interactive walkthrough of transaction and query flow through core YDB cluster components.
Write path
- Primary key design determines whether a write stays single-shard or becomes distributed.
- YDB uses serializable isolation with optimistic concurrency control; conflicting transactions may fail and require retry.
- Cross-shard writes usually cost more latency/resources than single-shard writes.
- DDL and DML are not combined in one transaction; schema changes are separate idempotent operations.
When to choose YDB
Good fit
- High-load transactional services that need strong consistency and automatic sharding without manual partitioning.
- Data and traffic grow continuously, and shared-nothing horizontal scale matters more than the simplicity of a single node.
- The OLTP contour and column-table analytics have to live side by side, so you avoid spinning up a separate system just for reports.
- The team is ready to invest in key design and distributed SQL operations — without that, the advantages never show up.
Avoid when
- A small single-node project: a local DB is simpler, and distributed complexity earns nothing here.
- A workload with frequent cross-shard transactions and no partition-aware key design — every such transaction pays in coordination.
- You need minimal operational complexity and have no resources to run a cluster.
- Full-text search or pure OLAP dominates without a transactional core — purpose-built engines are stronger here.
Practice: DDL and DML
Below are practical YDB examples at the data-definition (DDL) and data-manipulation (DML) level: schema and index design, transactional upserts, and key-range query patterns — the things you work with every day.
DDL and DML examples in YDB
DDL defines schema/partitioning, while DML covers transactional writes and analytical reads.
In YDB, DDL operations (tables, indexes, partitioning) are handled separately from DML transactions and should be idempotent.
Create row table with auto partitioning
CREATE TABLEPrimary key is mandatory; auto partitioning helps scale with data and load growth.
CREATE TABLE orders (
tenant_id Uint64,
order_id Uint64,
status Utf8,
amount Uint64,
created_at Timestamp,
PRIMARY KEY (tenant_id, order_id)
)
WITH (
AUTO_PARTITIONING_BY_SIZE = ENABLED,
AUTO_PARTITIONING_MIN_PARTITIONS_COUNT = 8
);Add global secondary index
ALTER TABLE ... ADD INDEXSecondary index improves non-key access paths but increases write-side overhead.
ALTER TABLE orders
ADD INDEX idx_status GLOBAL ASYNC ON (status);Create column table for analytics
CREATE TABLE ... STORE=COLUMNFor OLAP workloads, use column store and hash-based partitioning.
CREATE TABLE events_olap (
ts Timestamp NOT NULL,
tenant_id Uint64 NOT NULL,
event_type Utf8,
payload Json,
PRIMARY KEY (ts, tenant_id)
)
PARTITION BY HASH(tenant_id)
WITH (STORE = COLUMN);Related chapters
- Database Selection Framework - Before reaching for YDB, line up your requirements on consistency, scale, and operating cost — this chapter covers the way to choose.
- PostgreSQL: history and architecture - What to compare YDB against: classic OLTP with a primary node and replicas versus the distributed SQL execution model.
- Cassandra: architecture and trade-offs - The opposite end of the trade-off: distributed SQL versus an AP-oriented NoSQL model that favors availability over consistency — compared across consistency model and query shape.
- Distributed Transactions (2PC/3PC) - What sits behind the word “coordination”: how transactions are agreed and the price paid in latency and availability on distributed write paths.
- ClickHouse: analytical DBMS and architecture - Where the line falls: when YDB column tables are no longer enough and the contour should add a dedicated analytical system.
- CockroachDB: distributed SQL database and architecture - The closest analog to compare against: two distributed SQL platforms side by side — multi-region behavior, transactional guarantees, and operational profile.