Is Aurora DSQL your next database?

Amazon just announced a new service called Aurora DSQL (distributed SQL) a serverless, globally distributed database. This could be significant, as Amazon has lacked a truly scalable database solution beyond Aurora. While Aurora v2 never gained much traction, will this new service be the one? Let's see.

The new database was unveiled at Re:Invent 2024 in Las Vegas. Aurora DSQL promises several key features: it's highly available (SLA > 99.999%), multi-regional, postgres compatible (more on that later), and blazingly fast (wording may not be accurate).

The most impressive aspect of Aurora DSQL is its global scale. Databases have always been notoriously difficult to scale, and even more challenging to replicate worldwide. Until now, Spanner by Google Cloud was the only real option for large-scale distributed databases. It's arguably one of Google Cloud's most interesting and underrated engineering achievements (I recommend reading the technical article here - it's a masterpiece of software engineering).

AWS claims that their offer is 4x faster than spanner (in read and write), and globally distributed across multiple regions.

In order to make all of this happen, AWS had to Re:Invent some “database transaction technologies”.

To ensure that the database stays consistent across regions, under minime delays, AWS decoupled compute and storage. This technique is not new and used by other database companies like Neon. The only difference is that Neon is not real-time and global, while Aurora DSQL is.

To ensure each region sees commits in the correct order, Aurora DSQL uses Amazon Time Sync Service (who knew this service existed?), an EC2 add-on that synchronizes EC2 clocks using atomic clock satellites.

To be honest, this database looks very promising. But to achieve this kind of metric, you have to make concessions. AWS is not above the laws of physics…

At the time of writing this article, I didn’t find yet any kind of proof of the read/write metrics that AWS claims. Also the service is only available in 2 US region at the moment, so I don’t think it would be fair to test these features today.

An interesting benchmark would be to perform a write query in us-east-1 and see how much time it takes to propagate to eu-west-1 , many times, on Spanner and Aurora DSQL.

AWS claims that the service is Postgres compatible (first, what does this mean? is it to be able to connect to it using psql or to have (a subset or all) postgres features?).

This was the part that got me interested in the product. Postgres is always at the core of each application, is hard to get right, and most of the time costs a lot of money. Having a serverless solution on AWS (other that Aurora v2) would be awesome!

As of this writing this article, Aurora DSQL is missing a lot of feature from Postgres :

• Database (only one database per cluster)
• Views
• Triggers
• Foreign keys (a big one…)
• a lot of extensions, like pgvector or postgis
• 10k row update per commit

This is normal for a new service, even for AWS. This is still an early demo, it is for sure a very strong MVP.

I wanted to test it with some of my applications to see how it handles normal workload (dev workload, of course, since the service is still in preview). However, the authentication method is unusual. You need to use a URL-like token to connect to the database. While DBeaver supports this method well, and I successfully logged in following the tutorial, I couldn't connect any of my applications to the cluster (using prisma, or more traditional method…).

It could be a skill issue.

I also tried using the aws dsql command in the CLI, but the subcommand isn't available yet. Not surprising, since the service has only been live for 5 hours!

I don't think Aurora DSQL is ready to be your next database yet. While having a fast, globally replicated database is appealing, these advantages don't outweigh the lack of basic relational database features like foreign keys and triggers. Additionally, the authentication methods are still somewhat awkward at the time of writing this article.

If I needed a database today, serverless or not, I would still choose Neon, Railway, or even RDS.