Hacker News new | past | comments | ask | show | jobs | submit login

> your engineers working on adding features to your product instead of "managing and operating" a database?

That's the typical sales pitch for cloud offering, but I really fails to see how it applies to DB. Which part of “managing and operating” your database do you save when using such a service? And how big of a load did it put on your engineers in the first place?




As a Sysadmin who has spent a lot of time engineering systems to do specific tasks, I will tell you that there is a lot of effort that goes into your "production" database. Some of the tasks are not going to magically go away just because you use a managed cloud service for database - securing access to your database, monitoring basic metrics such as CPU, disk usage etc, making sure your data is backed up and tested for recovery. However, if you decide to self-host your production database, you've got more work such as

1. Keeping your database software up-to-date. Applying security patches without a huge downtime.

2. Managing the installation so that it is operating correctly - it's Systemd init files are okay and that it will come back to life should the server restart, logs are being stored correctly at an appropriate disk partition and that they don't fill up your data directory,

3. OS configuration aligns with your and your database software's needs. Which sysenvs did you set? were they changed as part of your OS updates?

All of the above are worth it in many cases. Spending a few days optimising the installation for your workload can make a huge difference and also empower you to use custom extensions like Timescale which is not so easy to do in some managed database services. Also, cost savings because you take that effort on yourself.


Your crown jewels backup/restore will always work. You can easily/always spin up a new db copy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: