PostgreSQL on Amazon Aurora Serverless goes live. Check the price tag before diving in, though

Source:- theregister.co.uk

Amazon Web Services has announced the general availability of PostgreSQL on its Aurora Serverless platform.

Aurora is part of AWS’s managed relational database service. An Aurora database can span multiple regions for low latency reads. The compute aspect of Aurora is separate from its storage, which is always spread over multiple availability zones (AZs) for resilience.

AWS is careful to describe its two Aurora database types as MySQL-compatible and PostgreSQL-compatible, meaning that the implementation is different from the standard versions of these open-source database beasts.

Aurora has two distinct pricing models. The original model is based on instances, with AWS recommending that you use multiple instances based on a model of primary plus one or more replicas. This is called “provisioned” service. You pay separately for compute instances, currently starting at $0.088 per hour for a db.t3.medium (the minimum for PostgreSQL) and storage at $0.11 per GB/month, and I/O at $0.22 per million requests.

A db.t3.medium has two virtual CPUs, 4GB RAM, 1,500 Mbps bandwidth and up to 5 Gigabit network performance.

The serverless model has an auto-scaling option, so you do not have to specify any instances. Instead, it is based on Aurora Capacity Units (ACUs), where each ACU is a combination of processing and memory (just like a database instance). You do have an option to specify minimum and maximum ACUs for your database.

Hammer, spanner and screw
Microsoft buffs up its open-source halo to fine sheen with PostgreSQL GUI in Azure Data Studio
READ MORE
It is not clear exactly how an ACU maps to a database instance. However you will pay currently $0.06 per ACU per hour, and the docs suggest two ACUs as a minimum. Storage and I/O is charged the same way as for provisioned Aurora.

This makes sense, in that serverless Aurora costs more than provisioned Aurora but has the benefit of auto-scaling, saving you money when you have variable or unpredictable workloads.

There are a few other wrinkles. A serverless DB cluster is only in one AZ, whereas a provisioned database cluster can optionally span multiple AZs. If your Aurora serverless database cluster becomes unavailable it will failover to another AZ, but AWS will have to recreate it there, which takes longer. “The Aurora Serverless failover time is currently undefined because it depends on demand and capacity availability,” say the docs. The data itself should not be affected since it already spans multiple AZs.

Failover will be rare though, AWS promises. In addition, auto-scaling should be quick since AWS maintains what it calls a “warm pool of database capacity” ready to be added to your serverless cluster.

Creating an Aurora database. Despite the announcement, at the time of writing PostgreSQL is still not on offer
Creating an Aurora database. Despite the announcement, at the time of writing PostgreSQL was still not on offer

Despite AWS’s announcement this week of general availability, when we went to create a serverless Aurora database MySQL 5.6 compatibility was the only option. We trust that PostgreSQL will be available soon.

When should you use serverless? Currently it is not quite as good as provisioned Aurora, and likely to be more expensive if you have a steady workload. It is ideal though if you have a highly variable workload, or want to try some experiments.

Both options are premium ones, in the sense that you are paying extra for a managed service with resilience and scalability built-in.

It is the serverless model that fits best with the cloud computing concept, and the hope must be that eventually it gains all the capabilities of the provisioned option and at a similar price.