YugabyteDB: YSQL, YCQL, and the PostgreSQL features still on the roadmap

YSQL and YCQL are two different front ends on one distributed engine

YugabyteDB ships two distributed SQL APIs and the choice between them is not cosmetic. YSQL reuses the PostgreSQL query layer, the project placing it alongside Amazon Aurora PostgreSQL, and inherits datatypes, queries, expressions, operators and functions, stored procedures, triggers and extensions from it. YCQL is the other one: a semi-relational SQL-like API with document and indexing support whose roots sit in Apache Cassandra QL. One front end targets teams that want PostgreSQL semantics, the other targets teams arriving from a wide-column store who still want a query language.

What this costs a reader is a doubled surface. Extensions, client drivers and documentation are chosen per API, and a capability present in one is not automatically present in the other. The same data problem has two answer shapes, so picking the wrong one means rewriting queries later rather than swapping a connection string. The stated design intent is that the query layer is extensible, which is why both APIs exist and why neither is presented as deprecated. Decide early, and read the API documentation for the one you choose, because the two have separate pages and separate feature lists.

Every read is strongly consistent until somebody turns that off

Reads are strongly consistent by default, and that default is the first thing to understand about the engine. Strong consistency of writes comes from Raft consensus for replication plus cluster-wide distributed ACID transactions driven by hybrid logical clocks, following the Google Spanner architecture the project credits. Three isolation levels are named explicitly: snapshot, serializable and read committed.

The tuning point sits on the read side. Queries can be tuned dynamically to read from followers and from read replicas, and read replicas are a supported way to serve stale data with low latencies. Consequence for a reader: an application written on the assumption that every read is linearizable has to be audited before you point it at a replica, because nothing in the API stops you from trading freshness for latency in a hurry. That trade is deliberate and it is where read-heavy workloads win, but it also means the guarantee a reviewer assumes is the one somebody disabled last week on a slow endpoint. Treat the default as the contract and record every query where you changed it.

The zero RPO and three second RTO belong to a single region

The availability numbers are precise and narrowly scoped. For a typical deployment where a YugabyteDB cluster runs in one region across multiple zones on a public cloud, the RPO is 0, meaning no data is lost on failure, and the RTO is 3 seconds, meaning data served by the failed node is available again within 3 seconds. Tolerance is configurable and named at the physical level, with disk, rack, node, zone, region and cloud failures each handled by native failover and repair.

Read that scope before repeating the figure. It describes one region across multiple zones. Multi-region and multi-cloud deployment is supported and can span three or more fault domains, but that is a different topology with a different failure model, and the 0 and 3 second pair is not restated for it. Consequence for a reader writing an availability commitment: the number you can quote to a customer comes from the single-region shape, and a design that crosses continents has to source recovery objectives elsewhere. Asynchronous xCluster replication between two regions, unidirectional or bidirectional multi-master, is a separate mechanism with its own lag, so a regional failover is not the three second path the headline describes.

PostgreSQL 15 compatibility and a cost based optimizer are open issues

The roadmap is the honest place to look for what the PostgreSQL layer does not do yet. PostgreSQL 15 compatibility is tracked as issue 9797, aimed at the latest features, new extensions, performance and community fixes. The PostgreSQL publication and replication slot API in change data capture is issue 18724, motivated by the size of the PostgreSQL community and its need for a compatible way to set up and consume database changes. Bitmap scan is issue 22653, covering index scans, remote filter and an enhanced cost model. A cost based optimizer is issue 10177, for plans driven by statistics such as table size, row count and data distribution.

Consequence for a reader: a query a PostgreSQL operator expects to get an index plan for may not, and plans on a distributed database can differ from the plan the same statement receives on a single node server. If your workload depends on a particular extension or on PG 15 syntax, check the state of the linked issue before designing around it. Bitmap scan matters most on large tables, so plan tuning done now may need revisiting after it lands. These entries are issue links rather than dated commitments, so treat them as direction, not schedule.

The engine is C and requirements.txt is contributor tooling

The repository is C, with CMakeLists.txt, src/, cmake_modules/ and build-support/ at the top level, plus a Python toolchain described by requirements.txt. That file is not a runtime dependency list for the database. It is build and lint tooling: autorepr, boto, botocore, codecheck, compiledb, compiler-identification, distro, downloadutil, llvm-installer, mypy, overrides, packaging, psutil, pycodestyle, pygithub, pytest, ruamel.yaml, semantic-version, six, sys-detection, types-psutil, types-requests, watchdog, wheel and yugabyte_pycommon. A second file, requirements_frozen.txt, sits beside it.

Consequence for a reader planning to build rather than install: a working development tree needs that Python toolchain provisioned first, and not one package in that list is a PostgreSQL extension or a client driver. Contributors should also expect mypy.ini, tox.ini, .clang-format, .clang-tidy, code_style.xml and Doxyfile in the same checkout, so the tree carries opinions about formatting, typing and documentation generation. For everyone else the path is the Quick Start documentation, or one of two demo applications the project points at: a microservices-oriented e-commerce app in Java, and a lodging recommendation service built with OpenAI and pgvector.

Cloud, managed and www sit in the same tree as the query engine

The top level is broader than a database server. Alongside src/, java/ and python/ sit cloud/, managed/ and www/, plus docs/, docker/, sample/, troubleshoot/ and pg15_tests/. Two version markers stand out: version.txt and min_yba_version.txt. The second is the informative one, because a minimum version file implies that something in this repository enforces a floor on the database version it runs against.

The contributor surface is broad in the other direction too. arcanist_util/, .arcconfig and .arclint cover Phabricator based review, REVIEW.md sits next to them, .circleci/ and jenkins_jobs.yml carry continuous integration, and .devcontainer/ provides a local container. Agent instruction files are checked in as well, in AGENTS.md and the .agents/, .claude/ and .cursor/ directories. Licensing has its own apparatus: .fossa-local.yml, .fossa-platform.yml, licenses/, codecheck.ini and NOTICE.txt beside LICENSE.md. Consequence: checks over this repository cover considerably more than the query engine, so a change local to one component can trip a gate owned by another.

sample/ is a set of SQL files rather than a loadable demo

The sample directory holds plain SQL rather than a demo harness with a runner. There are DDL and data pairs for Chinook, Northwind and clubdata, and a sportsdb set split across sportsdb_tables.sql, sportsdb_indexes.sql, sportsdb_constraints.sql, sportsdb_fks.sql and sportsdb_inserts.sql. Three directories cover specific topics: recursive-cte-code-examples/, date-time-utilities/ and covid-data-case-study/. There is also a file named airflowybrepo.sql, along with smaller files such as orders.sql, products.sql, reviews.sql, schema.sql and users.sql.

The layout is useful even with no loader, because it shows how the project expects a schema to be built. The sportsdb set separates tables, indexes, constraints, foreign keys and inserts into distinct files, which forces index placement and key distribution to be deliberate rather than an afterthought, and that separation is worth copying when you write your own DDL. Chinook and Northwind give you a small relational schema to point a client at while you are still learning whichever API you chose. Consequence: the Get Started section of the repository sends you to Quick Start documentation and to the demo applications rather than to a command that loads these files, so treat sample/ as reference material and load it with whatever client you already have.

Editorial conclusion

YugabyteDB fits teams that need multi-region or multi-cloud write scaling and want PostgreSQL syntax, and it fits badly if you need PostgreSQL 15 features today, bitmap index plans, or a guarantee that follower reads stay current. Before committing, read the linked roadmap issues for the version you plan to run, source recovery objectives for your actual topology rather than the single-region figure, and pick YSQL or YCQL deliberately, because that choice shapes your drivers and your queries rather than just your connection string.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. yugabyte/yugabyte-db on GitHub