GCP AlloyDB Blog Series Part 1 : The Introduction of AlloyDB for PostgreSQL

I haven’t written my blogs for quite some time as I have been quite busy with projects and other activities for the past few years. However, database is always my favorite technology and love to check out new database offering whenever I have time.

I used to work for a database startup, called Calpont (then changed the name to InfiniDB), starting as senior software developer, then as team lead for the database storage engine team. We literally built a column based MPP database from scratch. The InfiniDB is currently released under the name of MariaDB ColumnStore. My stay at Calpont was short, but I really enjoy working with a group of very smart developers at Calpont. One habit I started at Calpont was that I like to read all kinds of blogs or articles about the database internal, various database architecture, and database performance tuning. My job at Enkitec, then later bought by Accenture and currently becomes Accenture Enkitec Group (AEG), allows me to have an opportunity to work with many top database experts in the group and perform migration on some of the largest databases in the world. It’s very challenging, but a lot of fun. My experience at Calpont helps me to think from perspective of technology stack while my AEG‘s experience assists me to think from client’s perspective: what is the benefit to use a new database technology and how to get there?

For the past two years, open source database PostgreSQL has seen rise in popularity. More and more company migrate their on-prem databases to PostgreSQL based databases on the cloud. AlloyDB is the latest database offering based on PostgreSQL from Google Cloud. AlloyDB is a fully-managed, PostgreSQL-compatible database for both transactional and analytic workloads. It provides enterprise-grade performance, extensive HA and DR support with industry leading 99.99% availability. More introduction of the product can be found at Introducing AlloyDB for PostgreSQL: Free yourself from expensive, legacy databases

At its core, drawing from Google’s extensive experience with cloud technologies and underlined supporting infrastructure, AlloyDB takes database management to new heights by combining the best of both worlds. It inherits the well-established features of PostgreSQL while integrating with Google Cloud’s infrastructure, providing scalability and reliability to the customers.

There are some great articles about AlloyDB’s internal and why it can deliver impressive performance. Here is a list of the related articles:

By migrating to AlloyDB, organizations can achieves the following benefits:

  • Reduce cost : One of main reasons people want to move away from traditional databases, such as Oracle/DB2/SQL Server, is the license and support cost. No more cost hike due to license policies change and cloud hostile licensing policies.
  • Avoid license headache : traditional database vendors discourage customers from deploying traditional databases on other clouds. Customers have to engage external license consultants and attorneys to figure out whether they can deploy traditional databases to other clouds.
  • Support both transactional and analytic workload : AlloyDB goes beyond regular row format in PostgreSQL and introduce the dual format: both row format and columnar format. In this hybrid model, you can choose between row store or columnar store based on your need: transaction workload goes to row format while analytic workload goes to analytic workload.
  • Separate compute and storage : This is the similar design used by other GCP databases like, Spanner, BigTable and BigQuery. It separates the compute and storage at every layer of the stack based on the same Google infrastructure that support Gmail, YouTube, and Google Maps.
  • Scalability : AlloyDB is designed with scale-out storage, horizontal read, linear read scalability at up to 1000+ vCPUs and vertically scalable writes.
  • High SLA : Customers request highly reliable databases to their mission-critical workload. AlloyDB can detect and recovers from most database failures automatically independent of database size and workload. It can offer a high availability SLA of 99.99%.
  • No cloud vendor lock in : As the database is PostgreSQL based, the data can be migrated to any other PostgreSQL platforms in the future.
  • Simple pricing : One of the headaches when dealing with cloud based database, not only you need to pay for using the database service, but also complicated calculation based on the I/O usage. AlloyDB is simpler and transparent. Storage is automatically provisioned and customers are only charged for what they use. No additional storage cost for read replicas as well.
  • Full PostgreSQL compatibility : it uses standard PostgreSQL drivers and provide full compatibility with PostgreSQL. Therefore you can use the standard tools for migration, and operation.
  • Autopilot with ML : it includes automatic vacuum management, memory management, storage tiering, data columnarization and query rewrite.

There are two offering in the AlloyDB product family: AlloyDB running on GCP and AlloyDB Omni running anywhere you like. You can consider AlloyDB Omni is a self-managed version of AlloyDB without using Google Cloud’s infrastructure, but with the same underlined engine. You can deploy it on premise, at edge, and on other public or private clouds. AlloyDB Omni also uses the same columnar engine for fast scans, query joins and aggregations. Unlike AlloyDB is fully managed service on GCP, including backups and HA, the backup and HA on AlloyDB Omni are managed by customers. AlloyDB Omni can be used as the first step to test out the migration to AlloyDB from traditional databases, and provide a pathway for customers to migrate to AlloyDB Omni on-prem before moving to the cloud.

For the next few blogs in the series, I’ll explore more on how to install AlloyDB Omni, load TPCH benchmarking data, create AlloyDB cluster, connecting to AlloyDB environment using pgAdmin from your laptop, and performance comparison between AlloyDB Omni and PostgreSQL.