[Octabrain]

> RDS is ultimately a solution for people who look in the mirror and confidently say "you don't know how to run a database."

I think this is a terrible oversimplification and something tells me that you haven't had to deal with a complex database setup from an operations perspective. RDS reduces a huge overhead in terms of operations (ha, backups, upgrades and clustering being the first ones that come to my mind). Between RDS and running a database on a virtual machine(s) and manage it with, let's say, Ansible for providing the four aforementioned features I would chose RDS any day of the week.

[RaisingSpear]

> you haven't had to deal with a complex database setup from an operations perspective

I've often found it to be the opposite actually.

My experience is with RDS MySQL, and on that, RDS heavily restricts what you can do. Want to do partial replication? Nope. Want to install a database plugin? No access provided to do so.

Used to have a MySQL instance on EC2, but the rest of the team joined the cargo-cult of 'everyone else uses RDS, so it must be good'. I used to be able to grep replication logs to find problem queries, but RDS doesn't give you access to those. I used to use various I/O and CPU monitoring tools to help pinpoint bottlenecks in queries/performance, but you only get the few metrics RDS gives you (e.g. RDS only gives you aggregate CPU usage, not per-core usage).

Even stuff like killing queries gets annoying - standard MySQL GUIs typically issue a `KILL` statement, but you aren't given permission to execute that. RDS provides a workaround via a stored procedure, but that means you have to break into a console and remember the name of the SP.

Which leads to my next point - I think "managed" is a big misnomer. RDS is nothing like a truly managed DB with a DBA. AWS isn't assigning someone to optimise your tables, or won't help you look at your queries to see what can be done better. If something goes wrong, it's on you to fix it. IMO, RDS is more like a pre-configured database. It saves you from having to initially configure the database, and saves you from having to set up automated backups, HA etc.

My opinion is that, if all you need is a cookie-cutter solution, RDS is okay. If you need a complex setup, stay away.

[ckozlowski]

Spot on. RDS is a solution for people who look in the mirror and say "I'd rather be working on other things than running a database."

(Disclaimer: I'm a TAM for AWS.)

[tptacek]

In case it needs saying: Fly.io agrees with this! We didn't build our Postgres feature as a statement about the utility of managed Postgres; it's a statement about our size relative to AWS. :P

[sodapopcan]

...or their primary job has being dealing with a complex database setup and hasn't had to juggle that along with intensive application design.

Count me as someone who confidently doesn't know how to run a database and doesn't really care to. At least not at a level where someone would hire me to do it in production.

[jrockway]

I look in the mirror and confidently say I don't know how to run a database. Was the grandparent comment meant to be an insult?

[tshaddox]

It was clearly intended to dismiss managed databases altogether, so yes.

[Octabrain]

I didn't interpreted as such but as an oversimplification and a sign of lack of operations experience as I stated at the beginning of my comment.

[robertlagrant]

I don't think it's an insult. I don't know how to run a database; I want a managed service.

[Aeolun]

> you don't know how to run a database.

Hah, I wish you didn’t need to know how to run a database to use RDS. So much is dependent on settings/parameter groups.

[password4321]

Do you have any [pointers to] recommended best practices?