Mostly because databases are the key piece o data-persistence infrastructure. Spinning up a MySQL db to dev against, or a single server for a hobby project is quick and easy.

In production, all of a sudden you have a lot of work to do, especially around HA. Figure out replication, get it working, figure out how to monitor/alert if it stops working, figure out failover, figure out how to test that failover actually works, etc.

Support around that stuff has improved over the years, but it's still non-trivial and high-risk to DIY. It's a very different scenario than a stateless app server where you can have easy redundancy.

For me it isn't even this complicated. I just don't want to have to manage OS/MySQL/Postgres version upgrades or worry about having to troubleshoot when things on the server go south.

Just give me a database to connect to and take my money, please.

I think you mean, shut up and take my money :)

timdev2 sums up my original sentiment quite well. Is spinning up and maintaining a DB architecture doable? Of course... But there are so many complexities involved for real production that it would greatly slow us down.

If we had staff to dedicate directly to this then it wouldn't be an issue. But paying for a managed service that gives us production grade data access is a no-brainer for any non-trivial application we build.

and unless you're one of the elite few for whom good HA is actually easy, your attempts will likely end up with something that you _believe_ is as available as RDS

For a lot of situations, MySQL with backups and a hot standby is fine.

It's not about when things are going well... anyone here can setup a DB instance and run against it. It's failover/HA or recovery options that are not considered by most. Not everyone can afford to take a half a day or more to setup for backups, or read mirrors, or failover, other clustering options. Not to mention actual recovery modes.

I'm happy to pay a few dollars a month for someone else to automate.

It's not just the database itself, it's everything else you have to do to do it right. How will you do backups and replication? How will you recover? What are the ideal configuration settings for your particular situation? What about authentication, roles, open ports, allowed ip address ranges, etc.

Yep, that's my main motivation for not even attempting it. There are a ton of security settings alone. I am not gonna be the idiot who will let a 14-year old bored script kiddie into my VPS-es so they can have a laugh at my expense.

I prefer the managed services. Save for the high availability you get tons of best security practices -- all for a few bucks a month. It's usually a such a crazy cheap deal it's almost not fair to them.

Running your own DB is a recipe for disaster UNLESS you know what you are doing and can invest resources continuously in keeping it up. If you have a good DBA, it probably isn't too much of hassle as long as you scale up with the number of DBs and you have automation to help along the way. However, at that point you are almost to a hosted solution anyway.

For hobby projects, a single self-managed instance is fine. For production in a business critical environment, much more thought needs to go in.