YugabyteDB is designed with a logical architecture in two layers. In each database node, the upper half is the SQL processing layer that parses the SQL query, builds an optimized execution plan, and executes it. The application connects to a PostgreSQL backend, transforming the complex SQL execution into key-value read and write operations to be sent to the distributed transactional storage. This distributed storage is the lower half, which holds a part of the data on each node. Both logical layers are physically available on all nodes, making the deployment easier: all nodes are equal and active.

The two layers communicate through the network because any PostgreSQL backend can read and write data stored in any tablet, with some optimization to bypass the network stack when they happen to be on the same node. They are deployed on all nodes but scale for different reasons: the upper half scales because it is stateless, and the lower half scales because data is distributed.

The two-layer architecture allows for multiple query APIs. In addition to the SQL one, called YSQL, and using PostgreSQL, YugabyteDB provides a Cassandra-like API called YCQL.

Running both logical layers on all nodes simplifies the deployment, but you can disable one or the other to implement a physical separation of concern (SOC). A node will run only the query layer if there's no placement block defined for it and only the storage layer if the query endpoints (YSQL for the PostgreSQL API and YCQL for the Cassandra API) are not opened to the network.

Separation of compute and storage for databases - an example with YugabyteDB

Separating computing instances and persistence service, also known as disaggregation of compute and storage, gives the impression that the database servers can be stopped without losing the data service. Cloud vendors may market this as "serverless," but in reality, the physical architecture still i

linkedin.com