Amazon Aurora Serverless Gets More Detailed and Affordable

To further strengthen our commitment to providing industry-leading data technology coverage, VentureBeat is pleased to welcome Andrew Brust and Tony Baer as regular contributors. Check out their articles in the Data Pipeline.

Amazon Web Services (AWS) is updating its Amazon Aurora database to make serverless configuration more convenient and cost-effective. In the second version of the serverless capability, Amazon Aurora Serverless v2, which will significantly reduce scaling latency while making compute size much more granular and affordable, according to AWS.

Putting this in perspective, Amazon Aurora is a fully managed MySQL and PostgreSQL compatible database service. AWS mounts Aurora databases on its own optimized storage for increased scale and performance compared to the conventional attached storage vanilla MySQL and PostgreSQL databases it offers on its RDS service. AWS claims that its Aurora implementations are up to 5x faster than standard MySQL and 3x faster than standard PostgreSQL implementations.

The intelligent side of Aurora

Aurora Storage is designed as a distributed storage system, with a minimum of six instances maintained across three Availability Zones (AZs) within a region. The key to Aurora’s performance is the intelligence baked into the storage tier.

Aurora Serverless v2 is designed to reduce latency for scale-ups from minutes to less than a second and scale-downs to 15x, while enabling greater flexibility by supporting more granular compute sizing (expressed as Aurora Capacity Units or ACUs ). Like its originally provisioned counterpart, Aurora Serverless v2 supports the same replica footprint across three AZs within a region, with 1-15 instances depending on customer choice.

The finer granularity and related improvements are responsible for making autoscaling more efficient, making the process run almost instantly. It can reach hundreds of thousands of transactions without disrupting the workload.

Specifically, v2 of Aurora serverless can be scaled up or down in increments of just 0.5 ACUs and 1 GByte of memory, up to a maximum footprint of 128 ACUs including 256 GByte of memory. There is one subtle difference in the way AWS implements serverless in Aurora. It will not scale to zero, as transaction databases are assumed to operate in always-on mode; in this case; that’s a very different use from analytics, where it’s not uncommon to use a flat line, Amazon Aurora Serverless v2 keeps the lights on with a minimum of 0.5 ACU and 1 GByte of memory; but customers can still choose to manually stop the instances when not in use.

Conversely, customers can mix and match serverless and provisioned Aurora instances on the same cluster. For example, customers who shard their databases, such as by line organization or region, can designate some shards with fixed provisioned capacity and others for serverless. This is especially useful for organizations where workload patterns vary by workgroup or region. It even works within a single Aurora cluster where read replicas can be a mix of serverless and provisioned resources.

So why should you use serverless databases? Two triggers stand out. The first is the case for developer simplicity; just focus on developing the application and don’t worry about capacity planning or provisioning. The other is about traffic levels that naturally peak or are unpredictable. The cloud allows for serverless because, unlike on-premises, you don’t need to purchase just-in-case capacity. With all these serverless benefits, provisioning is usually a better deal if traffic is relatively stable and predictable – cloud providers will always give price breaks if you pre-commit to firm capacity.

The appeal of going serverless

Serverless was originally associated with operational NoSQL databases that have few requirements for strong ACID transaction capabilities, and where traffic levels were often less predictable than traditional transaction processing scenarios. AWS has always offered Amazon DynamoDB as serverless; significantly, many of AWS’s newer database offerings, including Amazon Timestream for time series; Amazon Keyspaces (for Apache Cassandra); and Amazon Quantum Ledger Database (QLDB) for immutable (blockchain-like) workloads, are also offered serverless by default. Serverless is also offered by default or as an option for NoSQL databases from Microsoft Azure, Google Cloud and independents such as DataStax.

But we are now seeing serverless expanding beyond NoSQL’s traditional operational niche. Google Cloud broke new ground with the introduction of BigQuery for analytics, originally just as a serverless pay-per-search service. Since then, they’ve added inset orders for organizations that demand more predictable monthly costs. And with Amazon Aurora, AWS has become one of the first to bring serverless to transaction processing. But it is no longer alone; a few weeks ago, Cockroach Labs joined the crowd by adding a serverless option to its distributed transaction database, initially within a single region.

We expect serverless, as an option, to become a checkbox item in the future, especially for cloud databases that support distributed deployment. While traffic to transaction databases has traditionally been considered more predictable than, say, live mobile apps, a retailer or content provider adding a new product or service targeting a different market or demographic may find that some demand patterns are also less predictable. Being able to mix and match serverless with provisioned instances like what Amazon Aurora Serverless v2 will support should fit the bill.

Disclosure: AWS is a dbInsight client.

VentureBeat’s mission is to be a digital city square for tech decision makers to learn about transformative business technology and transactions. Learn more about membership.

This post Amazon Aurora Serverless Gets More Detailed and Affordable

was original published at “https://venturebeat.com/2022/04/21/amazon-aurora-serverless-gets-more-granular-and-affordable/”