3 ms·

But it doesn't save much engineering time. You now need to manage those services, and the high mark-up means you need to invest effort in scaling things up/down

• Daishiman 5y ago
  So did you send your database logs to a centralized logging system? Did you set up roles and keys to access those systems? Are your roles integrated with the rest of your permissions system? Do you have a perf dashboard where you can see the real-time usage of your DBs? Have you already rehearsed updating your database version? The thing is that it's totally possible that you learned everything needed to set up the cluster, in my experience most database systems that aren't set up by a professional DBA will sooner or later hit a configuration or maintenance snag. Once that happens, you're pretty much totally on your own and for critical systems that downtime is going to cost you more than the costs of your infra. So you either need to have a DBA on retainer if you're serious about data integrity, or you pay management costs which means your system was set by literally the most expert people on the planet in the area. If you're running a cluster where performance is the highest priority and downtime and maintenance isn't a huge issue because you have a nice decent maintenance window and enough dev cycles to spend on staying up to date, for sure, go for it. But in my experience, if you care more about a system staying up, good managed infra is so much more reliable that it's not even a question.
  • noogle 5y ago
    > 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