Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Do you self-host your database?

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 236 posts

Re: Ask HN: Do you self-host your database?

#101

Post by geostar »

mekster wrote: post #84
geostar wrote: post #66

Earlier quoted context omitted.

Do you prefer docker over systemd units?

I always wonder what the point of running a docker version of a daemon you can easily run with OS package manager, especially for those well tested packages like databases. And then security patches are rolled out accordingly to be updated automatically by the OS service. Not sure how good with docker container is on this part.

Though I don’t use docker extensively anymore , but I think people generally new to tech use it to prevent any haywire situations that happen during configs

Re: Ask HN: Do you self-host your database?

#102

Post by don-code »

When I last tried, it, AWS RDS still required EBS-backed disks. It may be acceptable for 99% of use cases, but that means there's a ceiling around 60k IOPS, even with PIOPS disks.

Outside of RDS, you're afforded a bit more creativity in your performance profile: multiple disks in RAID 0, tiered storage (burstable AND, rather than OR, provisioned IOPS storage), and instance store, to name a few. I actually once witnessed one of our databases riding out a 400K IOPS storm for a few minutes.

Before I get downvoted: yes, these introduce risk into your data architecture. It's crucial to understand what these choices will do to your failure profile, and plan accordingly. In our case, fast-failover to a hot spare database, combined with total recovery within two hours, was enough of a compensating factor to manage that risk.

Re: Ask HN: Do you self-host your database?

#103

Post by dith3r »

vira28 wrote: post #8
dith3r wrote: post #3

I'm hosting own MySQL, Mongo and Elastic clusters. At the beginning it takes more time to setup than cloud providers solutions and require more knowledge and tooling to do some ops(upgrades, backups etc). But you know which version of db you are running and how it is configured. Additionally cloud providers own solutions are binding with one of them.

Agree. It's a trade-off. If one knows how to do a bit of ops then it's feasible to self-host. what's the scale of the application(s) that uses these data stores? How do you monitor these clusters?

Std. Grafana + Prometheus + node exporter + specific data source exporter

Re: Ask HN: Do you self-host your database?

#104

Post by p49k »

devoutsalsa wrote: post #39
buro9 wrote: post #34

Earlier quoted context omitted.

It was very little effort to setup. Used puppet to define everything I wanted the infra to be, and have pretty much left it be. It's only reachable from the app servers, backed up to tarsnap. It's really not a lot to learn and hasn't been a chore to operate.

I'm mostly thinking about all the stuff that goes wrong. Corrupted data files, server(s) die, monitoring, getting paged, backups, testing restores, yada yada. It works until it doesn't, and then the value you derive from self-hosting is questioned when there's a failure. If you can self-insure against shit happening & like doing so, then it's probably worth it. Mostly just point this out for the potential self-hoster…

In practice, both hardware and software used in production is 10 times as reliable as it was 10 years ago. I’ve seen less downtime on the average Dell rack server with RHEL than the average yearly AWS downtime.

Additionally, running a managed DB involves a lot of upkeep as well, it’s just a different set of tasks.

Re: Ask HN: Do you self-host your database?

#105

Post by andix »

codewithcheese wrote: post #86
ciconia wrote: post #52

We're currently transitioning from a multi-tenant 2TB postgres DB hosted on AWS RDS to using sqlite instead, a separate database for each client. We're doing this for multiple reasons: a) As our DB grew the service became very expensive, one of the biggest items in our AWS invoice; b) Keeping the PG servers up to date is a pain, we simply don't have time for this; c) We wanted to be able to migrate to other clouds an…

Slack used to partition their databases per workspace (customer) and then moved away from it. The "Disadvantages" section lists reasons not to do that. https://slack.engineering/scaling-datastores-at-slack-with-v... Two disadvantages that stand out for me are: 1. You must be able to scale the database up to your biggest customer and down to the your smallest this can be increasingly difficult to provision. 2. You are…

2. can be a huge security feature. If your web application only has access to the database of this one customer, you practically can't leak data from other customers by accident.

Re: Ask HN: Do you self-host your database?

#106

Post by gregwebs »

cutthegrass2 wrote: post #71
ciconia wrote: post #52

We're currently transitioning from a multi-tenant 2TB postgres DB hosted on AWS RDS to using sqlite instead, a separate database for each client. We're doing this for multiple reasons: a) As our DB grew the service became very expensive, one of the biggest items in our AWS invoice; b) Keeping the PG servers up to date is a pain, we simply don't have time for this; c) We wanted to be able to migrate to other clouds an…

This sounds super interesting, are you able to share any further detail? I'm currently wrestling with a 35TB Aurora DB and considering options for future growth. The system is multi-tenant and one of the options on the table is breaking out the tenants and hosting them on either their own system or alongside smaller subset of tenants.

The issue with this approach (other than isolation) is that the largest tenant may be orders of magnitude bigger than others and still need more sharding to perform well while their smallest still needs to share a db. Have you looked at TiDB (MySQL) or CRDB (PG)?

Re: Ask HN: Do you self-host your database?

#107

Post by forinti »

devoutsalsa wrote: post #24
buro9 wrote: post #15

Yes. A Postgres which is currently only 1TB in size. It's read heavy, the write workload is very low in tens to spikes of low hundreds per second whilst the read is in thousands per second. The workload is stable during traffic spikes due to app caching and CDN caching (for guests). I do this for cost reasons, self hosting the database is so much cheaper than the managed options that for the same cost I can run the e…

Cheaper in terms of $$$. If you like managing a database, I'm sure it's a good deal!

Postgresql is really easy to manage. I manage a few instances and I rarely have to do anything. They might consume just a few hours per year.

Oracle, on the other hand, requires a lot of babysitting and you'll probably be better off using their cloud (and still it will be more of a burden than Postgresql).

Re: Ask HN: Do you self-host your database?

#109

Post by andix »

I never used a managed database.

For smaller projects it's too expensive. I just deploy a dockerized database next to the application.

For bigger projects every customer so far wanted to have the data physically in their data center. So we just installed databases on VMs.

Re: Ask HN: Do you self-host your database?

#110

Post by moehm »

tester34 wrote: post #81
reacharavindh wrote: post #67

Earlier quoted context omitted.

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…

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.
Post reply on HN