Project: YugabyteDB (App Definition and Development / Database)
File: general.md

title: YugabyteDB FAQS headerTitle: General FAQ linkTitle: General FAQ description: YugabyteDB FAQ How does YugabyteDB work? When is YugabyteDB database a good fit? What APIs does YugabyteDB support? And other frequently asked questions. aliases: /preview/faq/product/ /preview/introduction/overview/ /preview/introduction/benefits/ menu: preview_faq: identifier: faq-general parent: faq weight: 10 type: docs unversioned: true rightNav: hideH3: true hideH4: true <!-- <div class="video-wrapper"> {{< vimeo 305074082 >}} </div> --> YugabyteDB is a high-performance distributed SQL database for powering global, internet-scale applications. Built using a unique combination of high-performance document store, per-shard distributed consensus replication and multi-shard ACID transactions (inspired by Google Spanner), YugabyteDB serves both scale-out RDBMS and internet-scale OLTP workloads with low query latency, extreme resilience against failures and global data distribution. As a cloud native database, it can be deployed across public and private clouds as well as in Kubernetes environments with ease. YugabyteDB is developed and distributed as an . YugabyteDB is a transactional database that brings together four must-have needs of cloud native apps - namely SQL as a flexible query language, low-latency performance, continuous availability, and globally-distributed scalability. Other databases do not serve all 4 of these needs simultaneously. Monolithic SQL databases offer SQL and low-latency reads, but neither have the ability to tolerate failures, nor can they scale writes across multiple nodes, zones, regions, and clouds. Distributed NoSQL databases offer read performance, high availability, and write scalability, but give up on SQL features such as relational data modeling and ACID transactions. YugabyteDB feature highlights are listed below. SQL and that allow multi-row access across any number of shards at any scale. Transactional backed by self-healing, strongly-consistent, synchronous . Low latency for geo-distributed applications with multiple and . Linearly scalable throughput for ingesting and serving ever-growing datasets. that brings consistent data close to users through multi-region and multi-cloud deployments. Optional two-region multi-master and master-follower configurations powered by CDC-driven asynchronous replication. to ensure uniform load across all nodes even for very large clusters. Built for the container era with and infrastructure portability, including . that automatically tolerates any failures common in the inherently unreliable modern cloud infrastructure. Fully functional distributed database available under . Starting in , YugabyteDB is the only open-source distributed SQL database to have built-in enterprise features such as Distributed Backups, Data Encryption, and Read Replicas. New features such as and are also included in open source. YugabyteDB has had the following major (stable) releases: in November 2023 in May 2023 in December 2022 in July 2022. in February 2022. (There was no v2.10 release.) in November 2021. in July 2021. in January 2021. in July 2020. in February 2020. in September 2019. in July 2019. in March 2019. in September 2018. in May 2018. in November 2017. Releases, including upcoming releases, are outlined on the page. The roadmap for this release can be found on . Starting with , YugabyteDB is 100% open source. It is licensed under Apache 2.0 and the source is available on . Yes, both YugabyteDB APIs are production ready. achieved this status starting with v1.0 in May 2018 while became production ready starting v2.0 in September

Reference deployments are listed in . Some features are marked Beta in every release. Following are the points to consider: Code is well tested. Enabling the feature is considered safe. Some of these features enabled by default. Support for the overall feature will not be dropped, though details may change in incompatible ways in a subsequent beta or GA release. Recommended only for non-production use. Please do try our beta features and give feedback on them on our or by filing a . is the 100% open source core database. It is the best choice for the startup organizations with strong technical operations expertise looking to deploy to production with traditional DevOps tools. is commercial software for running a self-managed YugabyteDB-as-a-Service. It has built-in cloud native operations, enterprise-grade deployment options, and world-class support. It is the simplest way to run YugabyteDB in mission-critical production environments with one or more regions (across both public cloud and on-premises data centers). is Yugabyte's fully-managed cloud service on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). to get started. For a more detailed comparison between the above, see . Please follow the steps in the to report a vulnerability to our security team. The policy outlines our commitments to you when you disclose a potential vulnerability, the reporting process, and how we will respond. Trade-offs depend on the type of database used as baseline for comparison. Examples: Amazon Aurora, Google Cloud Spanner, CockroachDB, TiDB Benefits of YugabyteDB Low-latency reads and high-throughput writes. Cloud-neutral deployments with a Kubernetes-native database. 100% Apache 2.0 open source even for enterprise features. Trade-offs None Learn more: Examples: PostgreSQL, MySQL, Oracle, Amazon Aurora. Benefits of YugabyteDB Scale write throughput linearly across multiple nodes and/or geographic regions. Automatic failover and native repair. 100% Apache 2.0 open source even for enterprise features. Trade-offs Transactions and JOINs can now span multiple nodes, thereby increasing latency. Learn more: Examples: Vitess, Citus Benefits of YugabyteDB Distributed transactions across any number of nodes. No single point of failure given all nodes are equal. 100% Apache 2.0 open source even for enterprise features. Trade-offs None Learn more: Examples: MongoDB, Amazon DynamoDB, FoundationDB, Azure Cosmos DB. Benefits of YugabyteDB Flexibility of SQL as query needs change in response to business changes. Distributed transactions across any number of nodes. Low latency, strongly consistent reads given that read-time quorum is avoided altogether. 100% Apache 2.0 open source even for enterprise features. Trade-offs None Learn more: Examples: Apache Cassandra, Couchbase. Benefits of YugabyteDB Flexibility of SQL as query needs change in response to business changes. Strongly consistent, zero data loss writes. Strongly consistent as well as timeline-consistent reads without resorting to eventual consistency-related penalties such as read repairs and anti-entropy. 100% Apache 2.0 open source even for enterprise features. Trade-offs Extremely short unavailability during the leader election time for all shard leaders lost during a node failure or network partition. Learn more: YugabyteDB is a good fit for fast-growing, cloud native applications that need to serve business-critical data reliably, with zero data loss, high availability, and low

Common use cases include: Distributed Online Transaction Processing (OLTP) applications needing multi-region scalability without compromising strong consistency and low latency. For example, user identity, Retail product catalog, Financial data service. Hybrid Transactional/Analytical Processing (HTAP), also known as Translytical, applications needing real-time analytics on transactional data. For example, user personalization, fraud detection, machine learning. Streaming applications needing to efficiently ingest, analyze, and store ever-growing data. For example, IoT sensor analytics, time series metrics, real-time monitoring. See some success stories at . YugabyteDB is not a good fit for traditional Online Analytical Processing (OLAP) use cases that need complete ad-hoc analytics. Use an OLAP store such as or a data warehouse such as . is a popular benchmarking framework for NoSQL databases. We benchmarked the Yugabyte Cloud QL (YCQL) API against standard Apache Cassandra using YCSB. YugabyteDB outperformed Apache Cassandra by increasing margins as the number of keys (data density) increased across all the 6 YCSB workload configurations. is another publicly available, cloud-enabled benchmark tool for data store systems. We ran NDBench against YugabyteDB for 7 days and observed P99 and P995 latencies that were orders of magnitude less than that of Apache Cassandra. Details for both the above benchmarks are published in . is a widely used framework to evaluate the behavior of databases under different failure scenarios. It allows for a database to be run across multiple nodes, and create artificial failure scenarios, as well as verify the correctness of the system under these scenarios. YugabyteDB 1.2 passes . See , YugabyteDB's distributed document store is common across all APIs, and built using a custom integration of Raft replication, distributed ACID transactions, and the RocksDB storage engine. Specifically, DocDB enhances RocksDB by transforming it from a key-value store (with only primitive data types) to a document store (with complex data types). Every key is stored as a separate document in DocDB, irrespective of the API responsible for managing the key. DocDB's , , and architecture are all based on the first published in 2012. provides an in-depth look into DocDB. In terms of the , YugabyteDB is a consistent and partition-tolerant (CP) database. It ensures high availability (HA) for most practical situations even while remaining strongly consistent. While this may seem to be a violation of the CAP theorem, that is not the case. CAP treats availability as a binary option whereas YugabyteDB treats availability as a percentage that can be tuned to achieve high write availability (reads are always available as long as a single node is available). During network partitions or node failures, the replicas of the impacted tablets (whose leaders got partitioned out or lost) form two groups: a majority partition that can still establish a Raft consensus and a minority partition that cannot establish such a consensus (given the lack of quorum). The replicas in the majority partition elect a new leader among themselves in a matter of seconds and are ready to accept new writes after the leader election completes. For these few seconds till the new leader is elected, the DB is unable to accept new writes given the design choice of prioritizing consistency over

All the leader replicas in the minority partition lose their leadership during these few seconds and hence become followers. Majority partitions are available for both reads and writes. Minority partitions are not available for writes, but may serve stale reads (up to a staleness as configured by the flag). Multi-active availability refers to YugabyteDB's ability to dynamically adjust to the state of the cluster and serve consistent writes at any replica in the majority partition. The approach above obviates the need for any unpredictable background anti-entropy operations as well as need to establish quorum at read time. As shown in the , YugabyteDB delivers predictable p99 latencies as well as 3x read throughput that is also timeline-consistent (given no quorum is needed at read time). On one hand, the YugabyteDB storage and replication architecture is similar to that of , which is also a CP database with high write availability. While Google Cloud Spanner leverages Google's proprietary network infrastructure, YugabyteDB is designed work on commodity infrastructure used by most enterprise users. On the other hand, YugabyteDB's multi-model, multi-API, and tunable read latency approach is similar to that of . A post on our blog titled goes through the above tradeoffs in more detail. A YugabyteDB universe packs a lot more functionality than what people think of when referring to a cluster. In fact, in certain deployment choices, the universe subsumes the equivalent of multiple clusters and some of the operational work needed to run them. Here are just a few concrete differences, which made us feel like giving it a different name would help earmark the differences and avoid confusion: A YugabyteDB universe can move into new machines, availability zones (AZs), regions, and data centers in an online fashion, while these primitives are not associated with a traditional cluster. You can set up multiple asynchronous replicas with just a few clicks (using YugabyteDB Anywhere). This is built into the universe as a first-class operation with bootstrapping of the remote replica and all the operational aspects of running asynchronous replicas being supported natively. In the case of traditional clusters, the source and the asynchronous replicas are independent clusters. The user is responsible for maintaining these separate clusters as well as operating the replication logic. Failover to asynchronous replicas as the primary data and fallback once the original is up and running are both natively supported in a universe. Users primarily turn to YugabyteDB for scalability reasons. Consistent hash sharding is ideal for massively scalable workloads because it distributes data evenly across all the nodes in the cluster, while retaining ease of adding nodes into the cluster. Most use cases that require scalability do not need to perform range lookups on the primary key, so consistent hash sharding is the default sharding strategy for YugabyteDB. Common applications that do not need hash sharding include user identity (user IDs do not need ordering), product catalog (product IDs are not related to one another), and stock ticker data (one stock symbol is independent of all other stock symbols). For applications that benefit from range sharding, YugabyteDB lets you select that option. To learn more about sharding strategies and lessons learned, see .