[amzn-throw]

* RDS is a managed relational database service. You got a database? We'll run it in the cloud for you. Exact same bits and bytes as you're running locally.

* Aurora is Amazon's own relational database. You can't run it yourself, only with Amazon. It can pretend to be either Postgres or MySQL. And it'll be cheaper and faster and have higher availability. But it won't be the exact same bits and bytes as your own Postgres, so there's some risks.

So far the stuff we said runs on clusters. You pick how big and how powerful and how many and in which AZ and configure how to scale it.

This has fairly pragmatic limits before at a certain point sharding and continuous horizontal scaling just gets too hard.

* Until Aurora Limitless that is which is, well probably not limitless (I don't know) but effectively.

* But you're still configuring cluster sizes and scaling policies. If you don't want to do that, Aurora has a Serverless option. It's the same Aurora but now you don't have to worry about scaling it yourself. The first version was Aurora Serverless but people said it wasn't very good.

* So they put out a 2nd one which is great and scales to zero.

* Now if you have globally distributed customers or care a lot about resiliency, you probably want your database in multiple regions. And you're going to be setting up eventual consistent updates for that. To make that easier there is Aurora Global Database, which is the same Aurora, but now with cross region replication.

* But it's not strongly consistent across regions. Aurora DSQL is. It's an even more bespoke version of Postgres. Actually it's not a relational database one at all, it just pretends to be one. But it uses atomic clocks and shit to cheat the cap theorem and give you global distribution and resiliency with strong consistency.

So in conclusion there's basically only 3 things here:

* RDS which is an unopinionated way of running a relational database in the Cloud

* Aurora, Amazon's highly opinionated relational database. That has Global, Serverless, and Limitless configuration options.

* And Aurora DSQL which is not Aurora a relational database at all but plays one on TV. But it gets to have the best of all worlds - SQL and NoSQL.

They probably should have called it something new but Aurora has good brand recognition. People know and trust Aurora.

In the long term all will probably continue to exist depending on where you are in your cloud journey. But I also expect that in the fullness of time if you're building a new Cloud native application and you don't have to worry about legacy migrations, you'll probably choose either DynamoDB or Aurora DSQL in 99.9% of cases.

[hanikesn]

>Aurora is Amazon's own relational database. You can't run it yourself, only with Amazon. It can pretend to be either Postgres or MySQL. And it'll be cheaper and faster and have higher availability. But it won't be the exact same bits and bytes as your own Postgres, so there's some risks.

That doesn't ring true to me. From my understanding rds aurora mostly replaces the storage engines of these DBs and the frontent mostly follows upstream releases and is compatible with them.

[evanelias]

You're spot on. GP is repeating the common misconception that "Aurora" is a distinct, from-the-ground-up relational database system which can "pretend" to be either MySQL or Postgres by reimplementing their protocols/front-end from scratch. But that isn't the case at all.

In reality, Aurora MySQL is clearly heavily based on the MySQL codebase, but with major changes specifically to InnoDB's persistence and MVCC layers. Aurora MySQL implements a physical replication system using shared storage, undo, and redo logging. The rest is otherwise compatible with MySQL because it is using a lot of MySQL code.

I haven't read up on Aurora Postgres, but I'd bet it's something similar being applied to the Postgres codebase.

It's entirely possible the custom storage components may share some common code between Aurora MySQL and Aurora Postgres, but a custom storage layer alone isn't a "relational database" which "pretends" to be other DBs. (In contrast, it appears that DSQL actually might be that – a custom system with a reimplementation of Postgres wire protocol.)

Not trying to knock Aurora btw, it's really interesting technology and is quite an achievement by Amazon. But the constant confusion about what Aurora even is creates some support burdens in the DB ecosystem.

[amzn-throw]

Oops, my bad.

[RemiGaudin]

Very nice write up! It makes even more sense if you compare with Azure and see that they have the same kind of offering with the exact same breakdown, i.e. Azure Database for PostgreSQL/MySQL which is the managed relational database solution, Azure SQL databases which is the in-house one (i.e. SQL Server modified for Cloud) and promise cheaper/faster/higher HA because that's their own opinionated technology, with serverless and hyperscale (i.e. limitless) configuration options. They don't have DSQL equivalent yet, but their NoSQL offer (Cosmos DB) already have SQL query language support and with some modifications & improvements could be their "best of all worlds" equivalent.

[benterix]

> f you're building a new Cloud native application and you don't have to worry about legacy migrations, you'll probably choose either DynamoDB or Aurora DSQL in 99.9% of cases.

If cloud-native means spending your life in AWS, that is.

[amzn-throw]

I meant an AWS cloud native application, yes.

But I use "cloud native" in a way that actually makes sense, not the way that GCP dubbed Kubernetes and all of it's ecosystem of friends "cloud-native".

"Native" development on a desktop OS means using primitives specific to that OS. As opposed to using something like Java Applets or Electron which will give you cross-platform compatibility, but you're not developing "natively" for the platform. That has the obvious pros and cons to each way.

Kubernetes is very much the Electron way: Rely on a generic high-level abstraction that will then create awkward bindings of running on abstract generic servers - whether they're in your data center or in the cloud.

Calling that "cloud-native" is some Orwellian post-truthness. I hate it.

If you want to develop in the cloud and make the most of it, use Azure, use GCP, use AWS, I don't care (not true: AWS is the best; use AWS). Just use the cloud provider's NATIVE primitives.

Otherwise, you might as well go back to running your own data centers, what are you even doing.

(Note: i'm just some guy. You don't have to listen to me. It's just what I think)

[Hixon10]

> But it uses atomic clocks and shit to cheat the cap theorem

It is public information?

[belter]

Only you, the person posting and the 20,000 in Vegas yesterday know about it:

See at this timestamp: https://youtu.be/LY7m5LQliAo?t=3507

[senderista]

DSQL is a disappointing public name. The code name was much cooler.