DBDB.io The Encyclopedia of Database Systems · Est. 2017
Database of Databases

Database Entry

AlloyDB


AlloyDB is a proprietary fork of PostgreSQL created by Google Cloud.[03]

Developer
Country of Origin
US
Start Year
2022
Project Type
Commercial
Derived From
PostgreSQL
Compatible With
PostgreSQL
Operating System
Hosted
License
Proprietary

Database Entry

AlloyDB


AlloyDB is a proprietary fork of PostgreSQL created by Google Cloud.[03]

Checkpoints[03]


In AlloyDB, WAL records are written to the storage layer synchronously. Then, the log processing service in the storage layer is responsible for replaying the logs continuously. AlloyDB supports checkpoints but there is no need for flushing the changes in the database layer to the storage layer.

Concurrency Control[04][05]


The concurrency control AlloyDB uses is the same as in PostgreSQL

Data Model[06]


AlloyDB uses PostgreSQL, which is an object-relational database.

Foreign Keys[07]


AlloyDB supports foreign keys the same as PostgreSQL

Hardware Acceleration[08]


The system runs on Google Cloud instances but there is no specific hardware required, although two VM instances are required for an AlloyDB primary instance.

Indexes[09]


The concurrency control AlloyDB uses is the same as in PostgreSQL and PostgreSQL supports B-tree, Hash, GIST, SP-GIST, GIN and BRIN index types.

Isolation Levels[10]


Isolation level in AlloyDB can be set through database flag "default_transaction_isolation", where it can be set to either “read uncommitted”, “read committed”, “repeatable read”, or “serializable”.

Joins[11]


AlloyDB builds on PostgreSQL where PostgreSQL supports the following three join strategies: nested loop join and it is possible to utilize the values from the row of the left relation as keys for scanning the right relation's index given that the right relation can be processed with index scan, merge join and hash join.

Logging[12]


AlloyDB uses the same logging format as PostgreSQL, which uses logical logging

Parallel Execution[13][14]


AlloyDB employs PostgreSQL, which enables both inter-operation parallelism, allowing for parallel execution of parts of the plan, and intraoperator parallelism, enabling partitioning and sharing of specific operators such as scans, joins, aggregation, and append across multiple processes.

Query Compilation


AlloyDB does not support code generation or JIT optimization.

Query Execution[15]


The columnar engine of AlloyDB uses a vectorized model where SIMD instructions are used when deemed suitable. Bloom filters are also used for optimization purposes, depending on the selectivity of the workload.

Query Interface[16]


AlloyDB supports SQL and Stored Procedures

Storage Architecture[03]


For AlloyDB, all the WAL records are written synchronously to the storage layer, where the records get processed by the log processing service.

Storage Model[15]


AlloyDB stores the data in the storage layer following the same format as PostgreSQL. However, a columnar engine is used where the data that gets loaded into memory can take on either the row-based format or the columnar format based on the workload, which is decided using machine learning models. As a result, query optimizations relating to columnar formats can be applied to the relevant data.

Storage Organization[17][03]


PostgreSQL uses heap files to store the database data. For AlloyDB, after the log processing service processes the WAL records, the resulting database blocks get sent back to the primary and replica instances from the storage layer.

Stored Procedures[16][18]


AlloyDB supports stored procedures. SQL, PL/pgSQL, and C are supported by default. In addition, extensions to PL/proxy and PL/v8 can be added to support additional procedural languages.

System Architecture[03]


AlloyDB disaggregates its database layer and its storage layer. As a result, each component of the database system becomes more elastic to scale. AlloyDB refers to the main unit of resource as a cluster, which consists of one primary instance and multiple read pool instances. The primary instance handles read/write requests while the read pool instances only have read access. The storage layer is shared between all cluster resources.

Views[19][20]


AlloyDB follows the same rule as PostgreSQL where both Materialized Views and Virtual Views are supported.

Citations

20 sources
  1. AlloyDB for PostgreSQL | Google Cloud google.com
  2. https://cloud.google.com/alloydb/docs google.com Dead — Check Archive
  3. AlloyDB for PostgreSQL intelligent scalable storage | Google Cloud Blog google.com
  4. 5. Concurrency Control :: Hironobu SUZUKI @ InterDB interdb.jp
  5. PostgreSQL: Documentation: 7.1: Multi-Version Concurrency Control postgresql.org
  6. PostgreSQL: Documentation: 18: 1.  What Is PostgreSQL? postgresql.org
  7. PostgreSQL: Documentation: 18: 3.3. Foreign Keys postgresql.org
  8. View instance details  |  AlloyDB for PostgreSQL  |  Google Cloud Documentation google.com
  9. PostgreSQL: Documentation: 18: 11.2. Index Types postgresql.org
  10. Supported database flags  |  AlloyDB for PostgreSQL  |  Google Cloud Documentation google.com
  11. PostgreSQL: Documentation: 18: 51.5. Planner/Optimizer postgresql.org
  12. 9. Write Ahead Logging (WAL) :: Hironobu SUZUKI @ InterDB interdb.jp
  13. PostgreSQL: Documentation: 18: 15.1. How Parallel Query Works postgresql.org
  14. PostgreSQL: Documentation: 18: 15.3. Parallel Plans postgresql.org
  15. AlloyDB for PostgreSQL Columnar Engine | Google Cloud Blog google.com
  16. PostgreSQL: Documentation: 18: CREATE PROCEDURE postgresql.org
  17. Introduction to PostgreSQL physical storage rachbelaid.com
  18. Supported database extensions  |  AlloyDB for PostgreSQL  |  Google Cloud Documentation google.com
  19. PostgreSQL: Documentation: 18: 39.3. Materialized Views postgresql.org
  20. PostgreSQL: Documentation: 18: CREATE VIEW postgresql.org
Revision #6