AlloyDB for PostgreSQL

I started a cluster and initial testing shows that alloydb is Postgres, so everything should just work. The blog post [1] has more details on the implementation [1].

[1]: https://cloud.google.com/blog/products/databases/alloydb-for...

From what I have read, it sounds to me as if they implemented a new storage engine. The needed hooks/interface were introduced gradually over the last two or three releases.

both of the mentioned features from Citus and Timescale are extensions on PostgreSQL, so they do not alter the way storage works in PostgreSQL in any meaningful manner.

AlloyDB Seems better compared to Aurora, and they seem to share a significant amount of design principles with log-shipping, but now with an extra caching layer at or near the database instance.

As for the 'columnar' features, from the release post it seems like AlloyDB does not specifically store the data at rest in a columnar format, but transforms the rows into columnar for analytical queries (but I'm not sure about that). That indeed improves performance of certain classes of queries.

Citus and Timescale are postgres extensions that focus on partitioning data primarily. Citus focused on scaling out across multiple nodes based on whatever primary key you wanted. Timescale focused on single-node and then added multiple nodes later, focused on time (or other integer-based values) and more utilities around time-based analysis.

The Citus team also had a columnar data storage extension that's finally more production ready and Timescale created their own implementation by using columnar data but still storing it in the default rowstore and handling the differences in the query layer.

Aurora Postgres and AlloyDB are fundamentally the same thing and involve taking the "top" portion of actual PostgreSQL (wire protocol, parser, query planner, etc) and attaching it to their own rebuilt storage layer. Since storage is the bottleneck, they can scale that out using their cloud architecture and make it seamless to the DB compute layer on top. Other open-source databases like Yugabyte also follow this approach with their own data layer implementation to add distribution and replication.

There are still some fundamental limitations with this approach which is why you still have the concept of instances and primary/replicas instead of one massive distributed instance like Spanner, but most customers want faster/scalable Postgres rather than shifting to a proprietary DB.

Did they publish cost estimates?

Not much about this is useful to open-source or upstream.

Supabase is a frontend and API wrapper around a normal Postgres instance. It does nothing to the database itself and is not an alternative to AlloyDB.

When did supabase start supporting analytical worklods?