Amazon Aurora PostgreSQL Serverless generally available: Autoscaling & automatic
In serverless news, Amazon Web Services (AWS) announced that Amazon Aurora with Postgre SQL compatibility now supports serverless. Find out some of the potential use cases and limitations for this service and if it is the right choice for your applications.
On July 9, 2019 AWS announced that Amazon Aurora with Postgre SQL compatibility now supports serverless.
Amazon Aurora Serverless is, according to the AWS news blog by Danilo Poccia: “an auto-scaling version of Amazon Aurora that automatically starts up, shuts down and scales up or down based on your application workload“. With this new update, the PostgreSQL-compatible edition of Aurora Serverless is generally available for the public to use.
With serverless, users will pay “by the second” for what they use in database capacity. Thus, users only pay when the database is currently active.
When you create a database with Aurora Serverless, you set the minimum and maximum capacity. Your client applications transparently connect to a proxy fleet that routes the workload to a pool of resources that are automatically scaled. Scaling is very fast because resources are “warm” and ready to be added to serve your requests.
According to AWS, Aurora PostgreSQL Serverless is available in the following regions: US East (N. Virginia), US East (Ohio), US West (Oregon), EU (Ireland), and Asia Pacific (Tokyo). Further regions across the globe will follow in the coming year.
View the documentation and user guide here to read more about setting it up, creating a DB cluster, setting capacity, and other helpful tips.
Use cases and limitations
When should someone use this? The documentation lists several potential use cases:
- Infrequently used applications: With the pay-per-second model, applications that don’t require much time or access may benefit from this model.
- New applications: Test out the size of new applications in order to see what resources it will need. Take advantage of autoscaling.
- Variable workloads: Pay for only what you use when an application goes through frequent usage dips and spikes.
- Unpredictable workloads: Use autoscaling to prevent overpaying for unpredictable application usage fluctuations.
- Development & test databases: Databases automatically shut down when they are not in active use.
- Multi-tenant applications: Manage individual database capacity.
Some of the current limitations include:
- The maximum table size for Aurora MySQL DB cluster is currently 64 tebibytes (Tib); for Aurora PostgreSQL DB cluster is currently 32 TiB.
- DB clusters must not be given a public IP
- Individual DB clusters require two AWS PrivateLink endpoints. If a user reaches their AWS PrivateLink endpoints, no new clusters may be created.
- Currently, no support for the following:
- Loading data from an Amazon S3 bucket
- Invoking an AWS Lambda function with an Aurora MySQL native function
- Advanced auditing
- Aurora Replicas
- Database cloning
- IAM database authentication
- Cross-region read replicas
- Restoring a snapshot from a MySQL DB instance
- Migrating backup files from Amazon S3
- Amazon RDS Performance Insights