| area of interest | Cloud SQL (PostgreSQL) | AlloyDB | Cloud Spanner (PostgreSQL interface) | |
|---|---|---|---|---|
| Functionality | PostgreSQL offering (Major Version) | 14, 13, 12, 11, 10, 9.6 (See support and deprecation policies). |
14 (Part of press release here) |
PostgreSQL interface does not support any particular versions. While deprecated features since PostgreSQL 9.2 are limited, there can still be unforeseen issues, like serial/sequence not being available as a type in Cloud Spanner See here for other compatibility issues that may be observed during migration. See here for known documented issues with comparing Cloud Spanner and the open source PostgreSQL variant. |
|
Database extensions support
View compiled extension list here |
62 extensions See the full list of supported extensions here |
69 extensions As compared to Cloud SQL, AlloyDB supports 4 additional open-source extensions: bloom, hypopg, test-decoding and wal2json. In addition, AlloyDB also supports 3 Google Cloud only related extensions, allowing for more functionality on Google Cloud - we'll cover these extensions in the later part of this document. See the full list of supported extensions here |
0 extensions Cloud Spanner does not support extensions, as seen here |
|
| Integration with GCP ecosystem |
Wide range of GCP services supported:
|
AlloyDB extension specifically supports integration to Vertex AI in Google Cloud, with google_ml_integration. Also expected to support basic app development - Cloud Functions, Cloud Run, App Engine, Compute Engine, Google Kubernetes Engine |
Wide range of GCP services supported:
|
|
| Usability | Networking access |
Public (internet) and private (VPC) access are both possible |
Private services access only Services using AlloyDB must either be in the same VPC network Other methods to expose access exists too, like using Shared VPC, or Jump box, or other Cloud Network tools like Cloud VPN |
Public (internet) access is possible Connect to it locally via psql and PGAdapter, or via client libraries in your application You will need Google Cloud credentials that has permissions to access Cloud Spanner |
| Cloud "Vendor-Locking" abstraction |
No locking Applications can interface connect to Cloud SQL with open source libraries like Knex.js, allowing for code to be agnostic to existence of AlloyDB |
No locking Applications can interface connect to AlloyDB with open source libraries like Knex.js, allowing for code to be agnostic to existence of AlloyDB |
Infra vs Code level agnosticity - Mild locking but can be better At the code level, client libraries specific to Cloud Spanner are needed If code level agnosticity is required, infrastructure must be bundled (e.g. docker image) with PGAdapter, but currently only supports 3 drivers today, each in Java, Go and Python, in "experimental support" status See more on PGAdapter's supported clients and limitations |
|
| Monitoring |
Comprehensive metrics are available with Cloud Monitoring Alerting is also possible with the metrics above In addition, Cloud SQL also has System Insights - a curated dashboard to provide more insights, but in "Preview" status |
Comprehensive metrics are also available with Cloud Monitoring, though all metrics here still in "Beta" status Alerting is also possible with the metrics above |
Comprehensive metrics are also available with Cloud Monitoring Alerting is also possible with the metrics above |
|
Query instrumentation to detect and analyze query performance problems |
Query Insights is supported |
Query Insights is supported, but in "Preview" status |
Query Insights is supported |
|
| Reliability | Service Level Agreement (SLA) |
99.95% - Monthly Uptime Percentage |
99.99% - Not clarified but should be referring to monthly uptime |
99.999% (Multi-Regional Instance) - Monthly Uptime Percentage 99.99% (Regional Instance) - Monthly Uptime Percentage |
| Security (Access control) |
Besides root access for admins, you need to create new users with Cloud SQL and assign RBAC explicity |
Similar to Cloud SQL in the need to create new users and perform RBAC, but AlloyDB also offers its own predefined set of roles in the PostgreSQL instance |
Supports Access Control with IAM - Tap on the flexibility and security benefits of IAM to assign database level rights, via user permissions and roles in Google Cloud However, note that Cloud Spanner provides for fine-grained access control (SQL based RBAC), but it is not available for the PostgreSQL interface in its preview status |
|
| Security (Data at rest) |
Data at rest are encrypted and protected using Google-managed default encryption |
|||
| Fault tolerance |
Supports High Availability (HA) configuration at a cost for the failover process, minimizing downtime Note that maintenance follows the failover workflow, even if HA option is not enabled |
Supports High Availability (HA) configuration at a cost for failover instance in a different zone |
Supports HA for failover by default |
|
| Maintenance Requirements |
Need to set maintenance window, which is the day and order to update relative to other databases, and minor disruptions to be expected when it happens Google Notice: "Maintenance typically only takes place once every few months, and requires your instance to be restarted while updates are made, which disrupts service briefly" A temporary "deny maintenance period" can be set to avoid unintended downtime due to maintenance if needed |
Maintenance is managed by GCP, with no expected downtime |
Maintenance is managed by GCP, with no expected downtime |
|
| Backup/Restore and Import/Export |
Cloud SQL supports scheduled backups over a 24h period and also on-demand backups Cloud SQL also supports export and import via SQL/CSV dump files to other Google Cloud tools like Cloud Storage |
Both scheduled backups and on-demand backups are supported features of AlloyDB Schedule configuration supports one or more days of the week, and multiple UTC times per day too. Multiple options to export data as a CSV or SQL file, makes it versatile for non-cloud backups, and reduce vendor locking |
Spanner supports Point-In-Time Recovery (PITR), which is configurable between 1 hour to 7 days Use earliest_version_time to recover either a portion, or an entire database, to some version time between the earliest time to now If a periodic backup that lasts more than 7 days is needed, you can also create a backup manually, using Cloud Scheduler |
|
| Performance | Query performance |
Standard open-source PostgreSQL, so performance should not deviate too much |
From Google's internal tests, AlloyDB is 4X faster for transactional workloads, and AlloyDB is also 100X faster for analytical queries, compared to standard PostgreSQL In addition, AlloyDB supports their own extensions to boost performance
|
Spanner's PostgreSQL interface is more of a standalone product, hence it's more of an "apples to oranges" comparison However, Spanner is built to work at scale, and the ability scale up horizontally across regions if needed for consistent throughput |
| Vertical Scalability |
Cloud SQL is vertically scalable You can enable this by choosing from a list of instances types at different CPU and RAM sizing, or a custom instance sizing However, there are min and max sizing limits to keep to |
AlloyDB is vertically scalable Instance config for vCPU and RAM ratio is fixed at 1:8, with available choices between 2, 4, 8, 16, 32, 64 |
Cloud Spanner is vertically scalable Parts of vertical + horizontal scalability is abstracted out as processing units OR nodes - as GCP's managed logic Monitoring and benchmarking are recommended for rightsizing |
|
| Horizontal Scalability |
Cloud SQL is not fully horizontally scalable Common scaling approach such as sharding is not available natively. However, you can still horizontally scale with master/slave approach using read replicas. |
AlloyDB is not fully horizontally scalable Like Cloud SQL, AlloyDB is also not available for any scaling approach, except for horizontally scaling with master/slave approach using read replica pool. |
Cloud Spanner is horizontally scalable |
|
| Autoscaling |
Cloud SQL cannot automatically scale the instance type used, and read replicas However, Cloud SQL does support automatic storage increase when available storage falls below a threshold size |
AlloyDB cannot automatically scale the instance type used, and read replicas However, AlloyDB supports Intelligent scalable storage, for storage increase |
Cloud Spanner supports autoscaling |
|
| Pricing See more detailed pricing comparisons here |
Cheapest consistently in most areas, like vCPU, Memory, and storage Available for 1-year and 3-year commitment pricing, which drives the costing even lower |
~40% to 50% more pricey compared to Cloud SQL Egress cost is the only area that can be competitively compared to Cloud SQL Also, no commitment option at the moment |
Most costly However, we should note that the computional units cannot be directly compared to vCPU and Memory costs, as it is a form of managed abstraction of resource for database use Multi-regional configuration can also drive up the cost further |
|
| Sustainability | Product Maturity |
Generally Available As of April 1, 2018 |
Not yet Generally Available, only at Preview stage At "Preview" stage, as of May 31, 2022 |
Generally Available As of June 23, 2022 |
| Region Availability |
Available in most if not all regions |
Limited availability at ~40% of GCP's supported regions |
Available in most if not all regions |
|
| Multi/Cross Region Support |
Cloud SQL does not support writes across regional databases, as it does not support horizonal scaling on writes Cloud SQL, however does support cross-region read replicas |
No support at the moment |
Supports pre-defined multi-regions Configurations varies between different combinations within one continent and three continents |
|
| Documentation |
Mature |
Incomplete Self experimentation with the tool was needed to check the limits, as not all of the knowledge is fully documented yet |
Mature |
|
*All information is accurate as of Sep 2022