Project: YugabyteDB (App Definition and Development / Database)
File: design-goals.md

title: Design goals headerTitle: Design goals linkTitle: Design goals description: Learn the design goals that drive the building of YugabyteDB. menu: v2.16: identifier: architecture-design-goals parent: architecture weight: 1105 type: docs This page outlines the design goals with which YugabyteDB has been built. YugabyteDB offers strong consistency guarantees in the face of a variety of failures. It supports distributed transactions. In terms of the , YugabyteDB is a CP database (consistent and partition tolerant), but achieves very high availability. The architectural design of YugabyteDB is similar to Google Cloud Spanner, which is also a CP system. The description about is just as valid for YugabyteDB. The key takeaway is that no system provides 100% availability, so the pragmatic question is whether or not the system delivers availability that is so high that most users no longer have to be concerned about outages. For example, given there are many sources of outages for an application, if YugabyteDB is an insignificant contributor to its downtime, then users are correct to not 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 acknowledgement 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. 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 should be true of 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. YugabyteDB supports multi-row transactions with three isolation levels: `Serializable`, `Snapshot` (same as "repeatable read") and `Read Committed` isolation. The API supports `Serializable`, `Snapshot` (default<sup>$</sup>) and `Read Committed` Isolation using the PostgreSQL isolation level syntax of `SERIALIZABLE`, `REPEATABLE READ` and `READ COMMITTED` respectively. The API supports only `Snapshot Isolation` (default) using the `BEGIN TRANSACTION` syntax. <sup>$</sup> - `READ COMMITTED` is the default isolation level in PostgreSQL and YSQL. If `ybenablereadcommittedisolation=true`, `READ COMMITTED` is mapped to Read Committed of YugabyteDB's transactional layer (that is, a statement will see all rows that are committed before it begins). But, by default `ybenablereadcommittedisolation=false` and in this case Read Committed of YugabyteDB's transactional layer maps to Snapshot Isolation. Essentially this boils down to the fact that Snapshot Isolation is the default in YSQL. Read Committed support is currently in

{{< tip title="YSQL vs PostgreSQL isolation levels" >}} Refer to the to learn how YSQL isolation levels map to the levels defined by PostgreSQL. {{< /tip >}} {{< tip title="Read more about consistency" >}} Achieving . How are achieved. in YugabyteDB. The architecture of . {{< /tip >}} YugabyteDB does not reinvent data client APIs. It is wire-compatible with existing APIs and extends functionality. The following APIs are supported. 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 of the PostgreSQL open source project. New changes do not break existing PostgreSQL functionality 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. Support wide SQL functionality: All data types Built-in functions and expressions Joins (inner join, outer join, full outer join, cross join, natural join) Constraints (primary key, foreign key, unique, not null, check) Secondary indexes (including multi-column and covering columns) Distributed transactions (Serializable, Snapshot, and Read Committed Isolation) Views Stored procedures Triggers is a semi-relational SQL API that is best fit for internet-scale OLTP and HTAP apps needing massive write scalability as well as blazing-fast queries. It supports distributed transactions, strongly consistent secondary indexes and a native JSON column type. YCQL has its roots in the Cassandra Query Language. {{< tip title="Read more" >}} Understanding . {{< /tip >}} Written in C++ to ensure high performance and the ability to leverage large memory heaps (RAM) as an internal database cache. It is optimized primarily to run on SSDs and NVMe drives. It is designed with the following workloads in mind: High write throughput High client concurrency High data density (total data set size per node) Ability to handle ever growing event data use-cases well {{< tip title="Read More" >}} Achieving . {{< /tip >}} YugabyteDB should work well in deployments where the nodes of the cluster span: single zone multiple zones multiple regions that are geographically replicated multiple clouds (both public and private clouds) In order to achieve this, a number of features would be required. For example, client drivers across the various languages should be: Cluster-aware, with ability to handle node failures seamlessly Topology-aware, with ability to route traffic seamlessly YugabyteDB is a cloud-native database. It has been designed with the following cloud-native principles in mind: Run on any public cloud or on-premises data center. This means YugabyteDB should be able to run on commodity hardware on bare metal machines, virtual machines, or containers. No hard external dependencies. For example, YugabyteDB should not rely on atomic clocks, but should be able to utilize one if available. The database should work natively in Kubernetes and other containerized environments as a stateful application. YugabyteDB is open source under the very permissive Apache 2.0 license. You can now read about the following: