> So did you send your database logs to a centralized logging system? Not needed. > Did you set up roles and keys to access those systems? Yes. > Are your r

> So did you send your database logs to a centralized logging system? Not needed. > Did you set up roles and keys to access those systems? Yes. > Are your roles integrated with the rest of your permissions system? Not needed. Access to the DB is limited to a very small circle, by design. Postgresql's mechanisms suffice. > Do you have a perf dashboard where you can see the real-time usage of your DBs? htop/task manager and Postgresql's internal monitoring have so far been sufficient. > Have you already rehearsed updating your database version? Indirectly yes, although AFAIK (happy to learn otherwise) major version update are also not supported by RDS. This has been working for years now, with actual paying customers (so "in production"). It's always about opportunity-cost and diminishing returns: RDS costs about as 3 developers. The benefit the product gets from 3 more developers far outweighs the benefit of another "9" in the SLA. Even if all of the savings would have gone to pay for a DBA, we'd still get a better deal: an in-house DBA will focus on addressing our specific needs. RDS also has a serious opportunity cost since it prohibits using extensions that are very useful for us, forcing us to spend time on workarounds. And frankly, it's not like RDS is even that reliable. We had multiple incidents where the database stopped responding or slowed down to a crawl for several hours, and we had now way to debug this (since we cannot access the server itself). They also don't seem to handle anything about Postgresql tuning. For the customer, the app slowing down (because RDS has a very limited IO bandwidth) is an outage (and is much more frequent than some system error). tl;dr: Many people can meet their needs with a Ford, and living on the streets to pay for the extra features of a Ferrari is not a good tradeoff for them. EDIT: line spacing