*Note: This article is an English translation of a post originally published in Japanese on March 11, 2025. The content reflects the Aurora DSQL preview period, prior to its General Availability.

Hello, I’m Hiro from Group 4 of the IT Platform Department. My primary role is to manage the infrastructure for mobile games that are released worldwide.

Today, I will introduce Amazon Aurora DSQL, which was announced at last year’s AWS re:Invent, in this article. I had been researching databases recently, and when I saw the Aurora DSQL announcement, I felt it was crucial to understand why and how it differs from existing databases.

In recent years, the era of relying solely on traditional relational databases (RDBs) has passed. We now have a diverse landscape of database products, including NoSQL and Distributed SQL, and we must choose the right tool for the right job. Especially for a company like DeNA, which offers large-scale services, selecting and utilizing the appropriate database is crucial for maintaining service continuity and managing operational costs. Aurora DSQL possesses features not found in previous databases, including Cloud Spanner, and understanding its characteristics will be vital for making informed decisions in the future.

In this three-part series, I will introduce the features and architecture of Aurora DSQL. This series is aimed at those with experience with RDBs, focusing mainly on architectural differences and the benefits of Aurora DSQL. Please note that this is not an exhaustive comparison, as is focusing on “What’s New”.

• What’s New in Aurora DSQL? (A Comparison with Traditional Aurora)
• What’s New in Aurora DSQL? (A Comparison with Spanner)
• What’s New in Aurora DSQL? (Summary + Deep Dive into Internals)

This is the first article in the series: “What’s New in Aurora DSQL? (A Comparison with Traditional Aurora).” To give you the conclusion upfront: Aurora DSQL is an Aurora database that has become more distributed, freeing users from management tasks even when operating at a massive scale.

Traditional Aurora

First, let’s review how traditional Aurora works.

A Design with Decoupled Compute and Storage Layers

Traditional RDBs (like MySQL and PostgreSQL) typically run a single database on a single server. While this configuration is simple, the entire system goes down if some of its parts(ex. storage) fails. Furthermore, you cannot exceed the performance of the server hosting the RDB. To improve performance, you either have to increase the server’s specs (scale-up) or combine multiple servers on the user side (e.g., through replication or sharding, which is discussed later).

In contrast, Aurora features a design where the compute and storage layers are separated. Looking at the architecture, you can see that the storage is decoupled into a single, large distributed storage system, and the compute layer, divided into a writer and readers, shares this storage sytem.

This distributed storage is Amazon Aurora storage .

Because of this design, Aurora’s storage scales automatically, and data replication and recovery from storage failures are fully automated. The compute layer doesn’t need to hold any data, which means data recovery is unnecessary during a failover, leading to high availability. While read throughput can be scaled by adding reader instances, a more subtle benefit is that it also has higher throughput than conventional RDBs. This is because Amazon Aurora storage only receives redo logs from the writer instance and performs the application of changes to data pages and replication in a distributed manner internally, eliminating the need for the writer to flush data pages.

What’s New in Aurora DSQL?

So, how has Aurora DSQL changed compared to traditional Aurora?

A Design Where Writes Are Also Distributed

Here is a high-level diagram of Aurora DSQL. While I’ll outline the function of each component below, it roughly shows a user’s update request coming from the left and being reflected in the Storage on the right.

The key change to note is that the write operations, which were previously handled exclusively by the writer instance in traditional Aurora, are now split into components called Query Processors and Adjudicators. This allows write operations to be processed in a distributed manner.

• Query Processor
  • The compute component that contains a customized Postgres engine.
  • It receives requests from users and executes read and write operations.
• Adjudicator
  • It checks whether a write operation initiated by a Query Processor would violate data consistency (i.e., if there are conflicting transactions).
• Journal
  • It receives data to be written, makes it durable, and asynchronously communicates the changes to the storage.
• Storage
  • It stores the data.

This new design gives Aurora DSQL the following advantages.

Benefit 1: Sharding is No Longer Necessary

Because write operations are also distributed, Aurora DSQL enables flexible scaling.

In traditional Aurora, write operations were handled solely by the writer instance. Scaling write throughput required a failover, which incurred a short period of downtime. If write throughput was insufficient even after scaling up to the largest instance class, it was necessary to implement sharding to distribute data across multiple Aurora clusters¹.

At DeNA, we use both failovers and sharding, but managing sharding imposes a significant operational burden. It requires correct schema and table design, to implement application data logic in a coordinated manner, and to manage app-database connections without any mistakes. As infrastructure engineers, we also have to scale in or out by splitting or merging shards carefully, when game data’s growth gets accelerated or slowed. We discuss these challenges in detail in the articles below(Please note that the articles are all in Japanese.).

However, with Aurora DSQL, which offers “virtually unlimited scalability”, you don’t have to make shards at all. This is an incredibly welcome feature for those who operate databases at a massive scale.

Benefit 2: Your Data is Always Up-to-date

In traditional Aurora, reader instances could return slightly stale data due to replica lag . This has been a particularly critical issue for DeNA, dating back to the days when we started using on-premise MySQL. For example, the problem of replication delay was mentioned in the book “The Technology Behind Mobage” published in 2012².

In a typical web application, there is a certain interval between user screen interactions, so a delay of 5 to 10 seconds is often not that serious.
However, in social games, many users are actively engaged, and screen interactions become extremely rapid.
Especially during limited-time events, it's not uncommon for users to click and navigate frequently to achieve significant results in a short period.
No matter how quickly they click, if the count of an item they just purchased doesn't increase, they would likely want to complain to the dev team.
So, the problem of MySQL replication delay in social games tends to be far more serious than in other web services.

This situation remains the same today. The application must either be designed to account for replica lag, or it must access to the writer instance when data freshness is critical. At DeNA, we intentionally increase replica lag in some testing environments to verify application logic.

However, your data is always up-to-date with Aurora DSQL. This is primarily because the data in storages is now versioned by timestamp, and each Query Processor can obtain an accurate timestamp locally³.

Because the Query Processor knows the exact timestamp one user request arrives, it can simply retrieve the version of the data from storages that corresponds to that timestamp to get the latest data⁴. The distinction between writers and readers in the Query Processor layer disappears, enabling distributed execution without replica lag.

This characteristic holds true even when Aurora DSQL is configured for multi-region deployment. Furthermore, it also brings the benefit of being able to read the latest data from within each local region, which (combined with optimistic concurrency control) can significantly reduce latency compared to simply issuing a query to a database in another region. This was a point that was especially emphasized in the CEO Keynote at re:Invent.

Example where communication with a DB in another region occurs for every read/write:

Aurora DSQL avoids cross-region communication except at commit time:

Benefit 3: Higher Availability With Zero Infrastructure Management

With traditional Aurora, we had to manage maintenance windows for applying patches and version upgrades, as well as for maintenance on the underlying hosts. These events often had a performance impact and could sometimes lead to downtime or manual instance replacement.

At DeNA, we have built systems to ensure reliable updates using Blue/Green deployments and to minimize downtime even when failovers are necessary. However, it would be preferable if these situations didn’t occur at all.

As stated on the official product page, “ There are no servers to provision, patch, manage, or upgrade ”, in Aurora DSQL, all of these tasks are no longer necessary. This is because the compute layer has also been made distributed, allowing AWS to perform maintenance and updates by replacing only the necessary components internally, without requiring any user awareness.

Furthermore, with the elimination of the writer instance as a Single Point of Failure (SPOF), availability has been raised to 99.999% in a multi-region configuration.

Points to Note for Aurora DSQL

While I’ve introduced the new aspects of Aurora DSQL, there are also some points of caution. As Aurora DSQL is a completely different system from its predecessors, it’s crucial to research and evaluate as a “different beast”, keeping the following points in mind.

Aurora DSQL Uses Optimistic Concurrency Control

Those who have worked with traditional RDBs or previous versions of Aurora are likely accustomed to pessimistic concurrency control. This is a mechanism where a lock is acquired on the target data before a write operation is performed (and waits if the lock cannot be obtained).

In contrast, Aurora DSQL uses optimistic concurrency control, so it does not acquire locks before updating data. Instead, if a conflicting transaction is detected, the commit will fail, requiring the user to retry the transaction. Workloads with high contention may actually perform worse. In particular, long-running batch processes that update large amounts of data could be a very poor fit.

Given that Aurora DSQL has a default transaction timeout of 5 minutes, its design is heavily weighted towards “providing low-latency for small, non-conflicting transactions”. This may require a fundamentally different approach to application design compared to what is used with traditional RDBs and Aurora.

Features Currently Unsupported

Currently, Aurora DSQL has many unsupported features. As of March 2025, various features such as views, triggers, and foreign key constraints are not available .

Since it is still in preview, the list of supported features is expected to grow. However, for the time being, it is necessary to carefully investigate the available features. It is also worth noting that MySQL is not yet supported, so there are no immediate plans for large-scale adoption at DeNA.

Conclusion

To summarize, Aurora DSQL leverages a design where writes are also distributed to provide the following benefits. Many of the user tasks that previously required meticulous attention are no longer necessary, making it especially beneficial for use cases that cannot tolerate downtime or that operate at a very large scale.

• Sharding is no longer necessary
• You can always access the latest data
• Availability is increased to 99.999% and maintenance tasks are eliminated

That said, Aurora DSQL is not a silver bullet, and it is not a complete superset of traditional Aurora. If the benefits listed above are of low importance for your use case, or if compatibility with existing code is a priority, then rushing to adopt Aurora DSQL even after it becomes generally available may not be the wisest choice. This article has only covered the high-level concepts, so I encourage you to understand the architecture and characteristics of both to use them effectively.

Next time, we’ll cover “What’s New in Aurora DSQL? (A Comparison with Spanner).” The characteristics of Aurora DSQL that I’ve introduced here are also features of Distributed SQL in general (as the DSQL name implies). I will compare it with Cloud Spanner, another prominent Distributed SQL database. As it turns out, Aurora DSQL is built on a different mechanism than Spanner, and the points to note mentioned in this article are related to that underlying architecture. I look forward to diving deeper into this topic in the next post.