Hetnzer, lol. Reminds me of all those weird Chinese brands for nvme and sdd hard drive enclosures on Amazon--Amaloo, Ugreen, Fideco, Orico, and on and on. All trash.
We cut our Mongo DB costs by 90% by moving to Hetzner
131–140 of 214 posts
Re: We cut our Mongo DB costs by 90% by moving to Hetzner
#132Earlier quoted context omitted.
> you're going to have multiple outages us: 0, aws: 1. Looking good so far ;) > AND incur more cross-internet costs hetzner have no bandwidth traffic limit (only speed) on the machine, we can go nuts. I understand you point wrt the cloud, but I spend as much time debugging/building a cloud deployment (atlas :eyes: ) as I do a self-hosted solution. Aws gives you all the tools to build a super reliable data store, but…
> many people just chuck something on us-east-1 and go Even dropping something on a single EC2 node in us-east-1 (or at Google Cloud) is going to be more reliable over time than a single dedicated machine elsewhere. This is because they run with a layer that will e.g. live migrate your running apps in case of hardware failures. The failure modes of dedicated are quite different than those of the modern hyperscaler cl…
The internet was designed to survive nukes.
Lets host it all with 2 companies instead and see how it goes.
Anyway random things you will encounter: Azure doesn't work because frontdoor has issues (again, and again) A webapp in Azure just randomly stops working, its not live migrated by any means, restarts don't work. Okay lets change SKU, change it back, oop its on a different baremetal cluster and now it works again. Sure there'll be some setup (read, upsell) that'll prevent such failures from reaching customers, but there is just simply no magic to any of this.
Really wish people would stop dreaming up reasons that hyperscalars are somehow magical places where issues don't happen and everything is perfect if you justtt increase the complexity a little bit more the next time around.
Re: We cut our Mongo DB costs by 90% by moving to Hetzner
#133Earlier quoted context omitted.
Most of the cost in their bill wasn't from MongoDB, it was cost passed on from AWS
Was it? Assuming an M40 cluster consists of 3 m6g.xlarge machines, that's $0.46/hr on-demand compared to Atlas's $1.04/hr for the compute. Savings plans or reserved instances reduce that cost further.
There's definitely MongoDB markup, but a full 33% of their bill was AWS networking costs that have nothing to do with Atlas.
Re: We cut our Mongo DB costs by 90% by moving to Hetzner
#134Earlier quoted context omitted.
Most of the cost in their bill wasn't from MongoDB, it was cost passed on from AWS
Highly doubt that. MongoDB has 5000 well paid employees and is not a big loss making enterprise. If most of the cost was pass through to AWS, they’d not be able to do that. Their quarterly revenue is $500M+ but also spend $200M in sales and marketing and $180M in R&D. (All based on their filings)
You can look at this particular bill and observe that more than 50% of the cost was going to AWS.
Re: We cut our Mongo DB costs by 90% by moving to Hetzner
#135> Here's how we managed to cut our costs by 90% You could cut your MongoDB costs by 100% by not using it ;) > without sacrificing performance or reliability. You're using a single server in a single datacenter. MongoDB Atlas is deployed to VMs on 2-3 AZs. You don't have close to the same reliability. (I'm also curious why their M40 instance costs $1000, when the Pricing Calculator ( https://www.mongodb.com/pricing )…
AWS and Azure were down for a full day in the past month.
No way I cannot spin up my infra in a full day even if the current datacenter burns to the ground.
So we have the same reliability.
Re: We cut our Mongo DB costs by 90% by moving to Hetzner
#136> Here's how we managed to cut our costs by 90% You could cut your MongoDB costs by 100% by not using it ;) > without sacrificing performance or reliability. You're using a single server in a single datacenter. MongoDB Atlas is deployed to VMs on 2-3 AZs. You don't have close to the same reliability. (I'm also curious why their M40 instance costs $1000, when the Pricing Calculator ( https://www.mongodb.com/pricing )…
> MongoDB Atlas is deployed to VMs on 2-3 AZs
I've not actually seen an AZ go down in isolation, so whilst I agree its technically a less "robust" deployment, in practice its not that much of a difference.
> these "we cut bare costs by moving away from the cloud" posts are catnip for HN. But they usually don't make sense.
We moved away from atlas because they couldn’t cope with the data growth that we had(4tb is the max per DB). Turns out that its a fuck load cheaper even hosting on amazon (as in 50%). We haven't moved to hertzner because that would be more effort than we really want to expend, but its totally doable, with not that much extra work.
> more maintenance tasks (installing, upgrading, patching, troubleshooting, getting on-call, etc) with lower reliability and fewer services, isn't an advantage.
Depends right, firstly its not that much of an overhead, and if it saves you significant cash, then it increases your run rate.
Re: We cut our Mongo DB costs by 90% by moving to Hetzner
#137OK guys, running on a single instance is REALLY a BAD IDEA for non-pet-projects. Really bad! Change it as fast as you can. I love Hetzner for what they offer but you will run into huge outages pretty soon. At least you need two different network zones on Hetzner and three servers. It's not hard to setup, but you need to do it.
I think you're being overly dramatic. In practice I've seen complexity (which HA setups often introduce) causing downtimes far more often than a service being hosted only on a single instance.
HA can be hard to get right, sure, but you have to at least have (TESTED) plan for what happens
"Run a script to deploy new node and load last backup" can be enough, but then you have to plan on what to tell customers when last few hours of their data is gone
Re: We cut our Mongo DB costs by 90% by moving to Hetzner
#138MongoDB Atlas is so overpriced that you can probably save already 90% by moving to AWS.
we saved 50% by moving from atlas to a three node cluster. Thats for a 6tb db (we moved because of size rather than cost, but its been a nice bonus)
Re: We cut our Mongo DB costs by 90% by moving to Hetzner
#139Why in the world do people choose Mongo over Postgres? I'm legit curious. Is it inexperience? Javascript developers who don't know backend or proper data modeling (or about jsonb)? Is this type of decision coming down from non-technical management? Are VCs telling their portfolio companies what to use so they have something to burn their funding on? It's just really confounding, especially when there's even mongo-api…
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?
Re: We cut our Mongo DB costs by 90% by moving to Hetzner
#140> Here's how we managed to cut our costs by 90% You could cut your MongoDB costs by 100% by not using it ;) > without sacrificing performance or reliability. You're using a single server in a single datacenter. MongoDB Atlas is deployed to VMs on 2-3 AZs. You don't have close to the same reliability. (I'm also curious why their M40 instance costs $1000, when the Pricing Calculator ( https://www.mongodb.com/pricing )…
> MongoDB Atlas is deployed to VMs on 2-3 AZs I've not actually seen an AZ go down in isolation, so whilst I agree its technically a less "robust" deployment, in practice its not that much of a difference. > these "we cut bare costs by moving away from the cloud" posts are catnip for HN. But they usually don't make sense. We moved away from atlas because they couldn’t cope with the data growth that we had(4tb is the…
> I've not actually seen an AZ go down in isolation
Counterpoint: I have. Maybe not completely down, but degraded, or out of capacity on an instance type, or some other silly issue that caused an AZ drain. It happens.