v2.23 Preview Preview release - not for production v2024.1 STS Stable release with standard-term support v2.20 LTS Stable release with long-term support v2.18 STS Stable release with standard-term support v2.14 LTS Stable release with long-term support Unsupported versions

Design goals

Goals and ideas considered during designing YugabyteDB

Scalability

YugabyteDB scales out horizontally by adding more nodes to handle increasing data volumes and higher workloads. With YugabyteDB, you can also opt for vertical scaling choosing more powerful infrastructure components.

Scalability

High availability

YugabyteDB ensures continuous availability, even in the face of individual node failures or network partitions. YugabyteDB achieves this by replicating data across multiple nodes and implementing failover mechanisms via leader election.

High Availability

Fault tolerance

YugabyteDB is resilient to various types of failures, such as node crashes, network partitions, disk failures, and other hardware or software faults and failure of various fault domains. It can automatically recover from these failures without data loss or corruption.

Fault tolerance

Consistency

YugabyteDB supports distributed transactions while offering strong consistency guarantees (ACID) in the face of potential failures. For more information, see the following:

Single-row linearizability

YugabyteDB supports single-row linearizable writes. Linearizability is one of the strongest single-row consistency models, and implies that every operation appears to take place atomically and in some total linear order that is consistent with the real-time ordering of those operations. In other words, the following is expected to be true for operations on a single row:

  • Operations can execute concurrently, but the state of the database at any point in time must appear to be the result of some totally ordered, sequential execution of operations.
  • If operation A completes before operation B begins, then B should logically take effect after A.

Multi-row ACID transactions

YugabyteDB supports multi-row transactions with three isolation levels: Serializable, Snapshot (also known as repeatable read), and Read Committed isolation.

  • The YSQL API supports Serializable, Snapshot (default), and Read Committed isolation EA using the PostgreSQL isolation level syntax of SERIALIZABLE, REPEATABLE READ, and READ COMMITTED respectively. For more details, see Isolation levels.
  • The YCQL API supports only Snapshot isolation (default) using the BEGIN TRANSACTION syntax.

Partition Tolerance - CAP

In terms of the CAP theorem, YugabyteDB is a consistent and partition-tolerant (CP) database which achieves very high availability at the same time. The architectural design of YugabyteDB is similar to Google Cloud Spanner, another CP system. The description of Spanner is also applicable to YugabyteDB. The key takeaway is that no system provides 100% availability, so the pragmatic question is whether or not the system delivers sufficient high availability that most users no longer have to be concerned about outages. For example, given that there are many sources of outages for an application, if YugabyteDB is an insignificant contributor to its downtime, then users are correct not to worry about it.

Split-brain is a computing scenario in which data and availability inconsistencies arise when a distributed system incurs a network partition. For YugabyteDB, when a network partition occurs, the remaining (majority for write acknowledgment purposes) Raft group peers elect a new tablet leader. YugabyteDB implements leader leases, which ensures that a single tablet leader exists throughout the entire distributed system including when network partitions occur. Leader leases have a default value of two seconds and can be configured to use a different value. This architecture ensures that YugabyteDB's distributed database is not susceptible to the split-brain condition.

Data distribution

YugabyteDB splits table data into smaller pieces called tablets and distributes these tablets across different nodes in the cluster for better performance, availability, and resiliency. YugabyteDB automatically re-balances the number of tablets on each node as the cluster scales.

Load balancing

YugabyteDB monitors and automatically re-balances the number of tablet leaders and followers on each node continuously. This leads to the distribution of reads and writes across multiple nodes avoiding hot-spots and ensuring efficient resource utilization.

Data locality

YugabyteDB supports colocated tables and databases which enables related data to be kept together on the same node for performance reasons.

Colocating tables

Security

YugabyteDB supports robust security measures, such as authentication, authorization, encryption at rest, encryption in transit, and auditing capabilities.

Operational simplicity

YugabyteDB has been designed with operational simplicity in mind, providing features like automated deployment, configuration management, monitoring, and self-healing capabilities to reduce operational overhead.

Heterogeneous workload support

Depending on the use case, the database may need to support diverse workloads, such as transactional processing, analytical queries, real-time data ingestion, time-series, and key-value workloads.

Transaction isolation levels

Transaction isolation is foundational to handling concurrent transactions in databases. YugabyteDB supports three strict transaction isolation levels in YSQL.

  • Read Committed EA , which maps to the SQL isolation level of the same name
  • Serializable, which maps to the SQL isolation level of the same name
  • Snapshot, which maps to the SQL Repeatable Read isolation level

In YCQL, it supports only Snapshot isolation using the BEGIN TRANSACTION syntax.

SQL compatibility

YSQL is a fully relational SQL API that is wire-compatible with the SQL language in PostgreSQL. It is best fit for RDBMS workloads that need horizontal write scalability and global data distribution, while also using relational modeling features such as joins, distributed transactions, and referential integrity (such as foreign keys). Note that YSQL reuses the native query layer of the PostgreSQL open source project.

In addition:

  • New changes to YSQL do not break existing PostgreSQL functionality.

  • YSQL is designed with migrations to newer PostgreSQL versions over time as an explicit goal. This means that new features are implemented in a modular fashion in the YugabyteDB codebase to enable rapid integration with new PostgreSQL features as an ongoing process.

  • YSQL supports wide SQL functionality, such as the following:

Cassandra compatibility

YCQL is a semi-relational CQL API that is best suited for internet-scale OLTP and HTAP applications needing massive write scalability and fast queries. YCQL supports distributed transactions, strongly-consistent secondary indexes, and a native JSON column type. YCQL has its roots in the Cassandra Query Language.

Query layer

Performance

Written in C++ to ensure high performance and the ability to use large memory heaps (RAM) as an internal database cache, YugabyteDB is optimized primarily to run on SSDs and Non-Volatile Memory Express (NVMe) drives. To handle ever-growing event data workload characteristics in mind, YugabyteDB ensures the following:

  • high write throughput
  • high client concurrency
  • high data density (total data set size per node)
  • ability to handle ever-growing event data use cases
High performance in YugabyteDB

Geographically distributed deployments

YugabyteDB supports Row Level Geo-Partitioning of tables. This enables a specific row to be placed in a specific geography. It leverages two PostgreSQL features, Table partitioning and Tablespaces to accomplish this elegantly.

Cloud-ready

YugabyteDB is a cloud-native database, and can be deployed out of the box in most public cloud services like AWS, GCP, and Azure. YugabyteDB also supports a mult-cloud deployement which enables a cluster to be spread across different cloud providers.

Running on commodity hardware

YugabyteDB has been designed with several cloud-native principles in mind.

  • Ability to run on any public cloud or on-premises data center. This includes commodity hardware on bare metal machines, virtual machines, and containers.
  • Not having hard external dependencies. For example, YugabyteDB does not rely on atomic clocks but can use an atomic clock if available.

Kubernetes-ready

YugabyteDB works natively in Kubernetes and other containerized environments as a stateful application.

Deploy in Kubernetes

Open source

YugabyteDB is 100% open source under the very permissive Apache 2.0 license. The source code is available on GitHub.

Learn more