Hacker News Reader

Hacker News

Comment by eric4smith | Hacker News Reader

Full thread

eric4smith

IMHO self hosting your database (even in the cloud) is the best way to do it.

You have control over the version.

You have control over features.

You have control over performance.

It’s tons cheaper for greater performance - especially when you go over a few hundred gigs.

Yes, the hosted ones have built in replication - but my data is far too valuable to put in the hands of a third party. If they lost it - they could only shrug and say sorry and that’s it. The TOS indemnifies them.

I think it’s kind of honestly lazy — to not take the management of your data in your hands if you run a database of any significant size.

That being said, we do replicate and backup 9 ways to Sunday.

View on HN

As with most things in infrastructure, it is a tradeoff to be considered properly.

A startup, where you'd rather have your engineers working on adding features to your product instead of "managing and operating" a database? Have a lot of money to throw at this problem, being aware that you are paying for convenience? then using RDS and such would probably be a better choice.

An established company/product with a team of people working at a non-crazy pace, and catering to steady enterprise customers? Would like to build a sustainable long-time infrastructure setup that is optimised for efficiency and cost? running your own Database chosen well for your needs, backed up and tested rigorously, and managed by people who cares for the company's infrastructure would be a better idea.

It is weird when large companies with a dedicated platform team choose to run so many databases for their teams/services on a PaaS. That clearly is an optimisation opportunity.

What do you mean by "managing and operating" a database?

Applying migrations? initial setup and configuration?

I think he means the usual stuff, so monitoring (disk space, memory, disk io, slow queries), patching (following mailing lists, emergency patch on sunday afternoon), failover, scaling (read replicas, multi master), backup, backup restore test, tuning, auth, security etc.

How does a cloud offering's going to help you with slow queries and tuning? Same for the security part (the biggest threats coming through your app anyway).

Honestly, I don't know and would like to know as well. Can you share some insights into how much a cloud database allows to be tuned?

I haven't used a cloud offering before, but OP was asking about managing and operating a database. And that list is what we do at work or at home.

> initial setup and configuration?

If you think there is nothing more to maintaining a database than initial setup and configuration, you are in for a rude awakening. Shit happens.

I mean how much time daily would it take on average?

I felt like generally you have nothing to do, except sometimes you gotta do something like respond to disk quota alert and stuff

you dont need to do much, i would say my time budget on self hosted replicated and backed up MySQL database administration is under 20 hours per year. yes the first couple years took more time (learning, building out a backup strategy) but id have the same amount of learning with a hosted solution so i don't consider that part of time spent.

> 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?

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

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.

And every thing you have control over you are also responsible for maintaining. If that's your thing, ok, but not everyone wants to be a DBA all day.

self hosting a now 300gb database using mariadb, been in production for 14 years with almost no downtime and very good performance. i do not DBA all day, i do it maybe once a year to do a version upgrade.

this perception of having to be special or only focus on sysadmin stuff for self hosting is incredible. cloud providers have managed diamond cartel levels of consumer propaganda in the tech sphere, its pretty amazing once you notice it.

It's not perception, it's empirical evidence. Every thing I've set up myself is another thing I'm responsible for maintaining. Each and every one of them generates some baseline of stress, because there's only so many things I can juggle in my head at once. I'm relieved when a concentrated economic effort allows me to throw money at something I'd rather replace with doing something else, something I like doing.

At the early startup stages, you barely have to touch it. It'll just merrily run without intervention for months.

At the stage where you need to spend a few hours a month dealing with it, you can afford to hire a DBA.

In my country, after certain size, pg on aws ec2 with a few capable dba/devops salary still cheaper than rds or aurora

In actually most countries. Even the USA. Depending on the size of course.

and most importantly, you have control over your DATA.

This is the MOST important reason no one talk about.

> self hosting your database (even in the cloud)

> my data is far too valuable to put in the hands of a third party

Confused, you self-host "in the cloud" without a third party involved? What does that mean? Are you not counting the party hosting your machine?

They're talking about running the db on a vm, setting it up and tuning it themselves. As opposed to a managed solution which is setup and tuned and hosted on a vm controlled by another company.

I'm still unclear on if the VM here is on a machine they own/on their own premises? Or is it under someone else's control? "In the cloud" sounded like the latter but it sounds like the intention was the former?

It means when you use the database service from AWS, they provision the machines and the replication and the database themselves.

Whereas you can get a machine on AWS and setup the database yourself.

They are talking about renting a VM from a cloud provider and setting up the DB themselves (example: EC2) vs renting a fully managed DB from a cloud service provider (example: RDS).

But if you're running on a VM from a cloud provider isn't your data still in the hands of a third party..??

Reply on news.ycombinator.com