4 ms·

Can Amazon please get RDS product management ducks in a row? You got RDS For PostgreSQL, Aurora PostgreSQL (provisioned), Aurora Serverless v1, Aurora Serverles

by zokier 2y ago

Can Amazon please get RDS product management ducks in a row? You got RDS For PostgreSQL, Aurora PostgreSQL (provisioned), Aurora Serverless v1, Aurora Serverless v2, Aurora PostgreSQL Limitless Database, Aurora Global Database, and now Aurora DSQL (with PostgreSQL compatibility). It's very confusing, the docs are confusing, and the even the tools are confused. I think this is pretty big contrast to something like S3 where the product feels far more clearly and coherently managed, and where they have released lots of big improvements/changes over the years without disrupting or muddying the core product in major ways.

bradhe 2y ago
RDS generally is a massive, massive business inside AWS. I'd imagine the politics and organization generally is an absolute nightmare.
korkybuchek 2y ago
> It's very confusing, the docs are confusing, and the even the tools are confused. Not to worry -- you can use Rufus...uh "Q"....uhh...Nova...to summarize the docs into a decision tree on which confusing choice to use!
- OJFord 2y ago
  Except you can't, because it will just misundertand you or say something hopelessly generic. Even asking it something on the same page that it's advertised 'now supports asking about' completely failed for me - think it was ENIs or something; just said something completely generic, not at all about the instances I'd asked about which it advertised being able to do (and I happened to have a concurrent need for).
dakiol 2y ago
> It's very confusing As a very naive person myself, isn’t “being very confusing” one of the main points of AWS? They know they are big and nobody will get fired for using AWS. So, the more confusing their products are, the more benefits for them (e.g., because you don’t know how much you will pay, because you are misusing their products, because perhaps you don’t actually need their products, etc) So, any manager at AWS probably thinks this is all working very fine.
- mannyv 2y ago
  AWS is confusing because they have a lot of tools that differ in dimensions that 80% of the users don't understand. If you don't understand, for example, the difference between MySQL and PostgresQL then RDS/PostgresQL and RDS/mysql are the same. How does aurora mysql and aurora PostgresQL differ from standard RDS versions? Well, you have to actually read and understand...or watch some yoyo's YouTube video explainer. AWS is complicated because it offers a lot. Do you want a satellite downlink? AWS has that. How about a private 5G cell network? Yep. How about a distributed data store with basically fixed read latency? Well, there are a bunch of different options depending on what you want. Because you're obviously not used to being in the enterprise space, you think that confusion is what they want. They don't. In the space where people spend the big bucks being totally clear is what every good vendor strives for. You're in a multi-year relationship with these companies, and you want them to succeed. AWS isn't Oracle. Obviously there are tons of shops that will sell people the wrong thing. But then another shop comes along and takes their business (which is one project I'm involved with now - they have like some ridiculous RDS bill that shouldn't be more than $500/mo).
alexey-salmin 2y ago
Is it? Every solution has some advantages, switching between them is relatively easy (especially if you can tolerate some writing downtime), and IMO it's not that confusing if you have at least some experience in the space. Otherwise if you're just staring from scratch, I'd pick provisioned aurora if your load is steady and serverless v2 if not. Then IO optimized if the db doesn't fit into memory and non-IO-optimized until it does.
- zokier 2y ago
  It's not just selecting the service. It's also trying to decipher which parts what docs apply to when reading. Or how different services interact. Or getting any understanding what "Aurora" means in different contexts. Just random example I was poking around AWS Backup recently, and there you have option to enable Backup for different services. Among the other options, you have separate toggles for "Aurora" and "RDS". Overall the whole RDS API has lots of weirdness because there are all these different things (and combinations of things). Another random example, configuring Data HTTP API, you got this thing: https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_EnableHttpEndpoint.html https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/AP... > This operation applies only to Aurora Serverless v2 and provisioned DB clusters. To enable the HTTP endpoint for Aurora Serverless v1 DB clusters, use the EnableHttpEndpoint parameter of the ModifyDBCluster operation. At least that specific case was nicely documented now. Not all the pitfalls are thst clear.
oblio 2y ago
> Aurora Serverless v1 This is deprecated.
amzn-throw 2y ago
* 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.
- senderista 2y ago
belter 2y ago
Is that really the case? It appears to be a recent generational trend to openly flaunt one's ignorance...Admit you've never read the documentation but prefer to "learn on the job," criticizing Certifications, and having no patience for attending formal training.
deleted 2y ago
[deleted]

by zokier 2y ago

bradhe 2y ago

RDS generally is a massive, massive business inside AWS. I'd imagine the politics and organization generally is an absolute nightmare.

korkybuchek 2y ago

> It's very confusing, the docs are confusing, and the even the tools are confused. Not to worry -- you can use Rufus...uh "Q"....uhh...Nova...to summarize the docs into a decision tree on which confusing choice to use!

OJFord 2y ago
Except you can't, because it will just misundertand you or say something hopelessly generic. Even asking it something on the same page that it's advertised 'now supports asking about' completely failed for me - think it was ENIs or something; just said something completely generic, not at all about the instances I'd asked about which it advertised being able to do (and I happened to have a concurrent need for).

dakiol 2y ago

> It's very confusing As a very naive person myself, isn’t “being very confusing” one of the main points of AWS? They know they are big and nobody will get fired for using AWS. So, the more confusing their products are, the more benefits for them (e.g., because you don’t know how much you will pay, because you are misusing their products, because perhaps you don’t actually need their products, etc) So, any manager at AWS probably thinks this is all working very fine.

mannyv 2y ago
AWS is confusing because they have a lot of tools that differ in dimensions that 80% of the users don't understand. If you don't understand, for example, the difference between MySQL and PostgresQL then RDS/PostgresQL and RDS/mysql are the same. How does aurora mysql and aurora PostgresQL differ from standard RDS versions? Well, you have to actually read and understand...or watch some yoyo's YouTube video explainer. AWS is complicated because it offers a lot. Do you want a satellite downlink? AWS has that. How about a private 5G cell network? Yep. How about a distributed data store with basically fixed read latency? Well, there are a bunch of different options depending on what you want. Because you're obviously not used to being in the enterprise space, you think that confusion is what they want. They don't. In the space where people spend the big bucks being totally clear is what every good vendor strives for. You're in a multi-year relationship with these companies, and you want them to succeed. AWS isn't Oracle. Obviously there are tons of shops that will sell people the wrong thing. But then another shop comes along and takes their business (which is one project I'm involved with now - they have like some ridiculous RDS bill that shouldn't be more than $500/mo).

alexey-salmin 2y ago

Is it? Every solution has some advantages, switching between them is relatively easy (especially if you can tolerate some writing downtime), and IMO it's not that confusing if you have at least some experience in the space. Otherwise if you're just staring from scratch, I'd pick provisioned aurora if your load is steady and serverless v2 if not. Then IO optimized if the db doesn't fit into memory and non-IO-optimized until it does.

zokier 2y ago
It's not just selecting the service. It's also trying to decipher which parts what docs apply to when reading. Or how different services interact. Or getting any understanding what "Aurora" means in different contexts. Just random example I was poking around AWS Backup recently, and there you have option to enable Backup for different services. Among the other options, you have separate toggles for "Aurora" and "RDS". Overall the whole RDS API has lots of weirdness because there are all these different things (and combinations of things). Another random example, configuring Data HTTP API, you got this thing: https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_EnableHttpEndpoint.html https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/AP... > This operation applies only to Aurora Serverless v2 and provisioned DB clusters. To enable the HTTP endpoint for Aurora Serverless v1 DB clusters, use the EnableHttpEndpoint parameter of the ModifyDBCluster operation. At least that specific case was nicely documented now. Not all the pitfalls are thst clear.

oblio 2y ago

> Aurora Serverless v1 This is deprecated.

amzn-throw 2y ago

* 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.

senderista 2y ago

belter 2y ago

Is that really the case? It appears to be a recent generational trend to openly flaunt one's ignorance...Admit you've never read the documentation but prefer to "learn on the job," criticizing Certifications, and having no patience for attending formal training.

deleted 2y ago

[deleted]