Live data from Hacker News

We cut our Mongo DB costs by 90% by moving to Hetzner

prosopo.io

211–214 of 214 posts

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#211
post #109

Always consider if 12 hours of lost revenue is worth the savings. Recently hetzner has been flakey with minimum or no response for support or even status updates that anything was wrong. My favorite was them blaming an issue on my side just to have a maintenance status update the day after about congestion.

If I understand correctly, the author's company provides a CAPTCHA alternative, which presumably means that if their service goes down, all of their customer's logins, forms, etc. either become inoperable or don't provide the security the company is promising by using their service. This makes me want to use the company's service less because now I know they can't survive an outage in a consistent and resilient way.

We have 14 servers and counting running the frontend captcha service, we have a high uptime which you can observe here: https://portal.prosopo.io/status

We have extra provisions for enterprise clients to provide rock solid SLAs for every use case.

The db in question is our data store for event that we use for aggregated features such as traffic analysis and ml. This service lags behind our realtime services so we can deal with some downtime if necessary

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#212
post #200

Earlier quoted context omitted.

What does that mean, though? If I'm storing data on a NAS, and I keep backups on a tape, a simple hardware failure that causes zero downtime on S3 might take what, hours to recover? Days? If my database server dies and I need to boot a new one, how long will that take? If I'm on RDS, maybe five minutes. If it's bare metal and I need to install software and load my data into it, perhaps an hour or more. Being able to…

You're confusing backup with high availability. Backups are point in time snapshots of data, often created daily and sometimes stored on tape. It's primary usecase is giving admins the ability to e.g restore partial data via export and similar. It can theoretically also be used to restore after you had a full data loss, but that's beyond rare. Almost no company has had that issue. This is generally not what's used in…

> With that setup you're already able to hit 5 nines

This is "five nines every year except that one year we had two freak hardware failures at the same time and the site was hard down for eighteen hours".

"Almost no company has this problem" well I must be one incredibly unlucky guy, because I've seen incidents of this shape at almost every company I've worked at.

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#213
post #166
post #52

Earlier quoted context omitted.

My Hetzner instances all have higher reliability and uptime than AWS deployments. For years now. That was an interesting surprise.

Curious what kind of deployments you are running with them? I only have personal stuff with Hetzner; but never had issues so far (bare metal in my case coz cheap for what I get and need).

Mostly EC2 type VMs with docker clients in them. Keeping infrastructure simple is important for us :)

Re: We cut our Mongo DB costs by 90% by moving to Hetzner

#214
post #60

Earlier quoted context omitted.

I'll repeat it again: you don't always want a relational database. Sometimes you need a document-oriented one. It matches quite a lot of use cases, e.g. when there aren't really interesting relations, or when the structures are very deep. That can be really annoying in SQL. > when there's even mongo-api compatible Postgres solutions With their own drawbacks.

> Sometimes you need a document-oriented one. Like a file system?

Yeah, go ahead, query the file system.
Post reply on HN