Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We now use a DigitalOceans managed database with 0 standby nodes, coupled with another instance running Django. It is working good.

We are however actually thinking about switching to a new dedicated server at another provider (Hetzner) where we are looking at having the Web server and the DB on the same server, however the new server will have hugely improved performance (which is sometimes needed), still at a reduced cost compared to the DigitalOcean setup.

The thing we are doubting is if having a managed db is worth it. The sell in is that everything is of course managed. But what does this mean in reality? Updating packages is easy, backups as well (to some extent), and we still do not use any standby nodes and doubt we will need any replication. So far we have never had the need to recover anything (about 5 years). Before we got the managed db we had it in the same machine (as we are now looking at going back to) and never had any issues.

Any input?



Do note that with dedicated servers you are subjecting yourself to things such as hardware upgrades and failures which you will have to manage yourself if you want to prevent downtime.

And while Hetzner customer support is generally excellent, in my experience, their handling of DDoS incidents will generally leave your server blackholed and sometimes requires manual intervention to get back online.

This is something you need to account for in terms of redundance if you are planning to expose your application directly to the net without any CDN/Load balancer/DDoS filter in place.

From my experience it makes sense to work with a data centre that is less focussed on a mass market but allows for individual client relations to mitigate risks like that. I love Hetzner for what they are and do host some services with them, but I wouldn't build a business around services hosted there.

And this not only goes for Hetzner but pretty much any provider whose business model is based on low margin/high throughput.


Oh, their DDoS protection was one of the reasons we were thinking about moving away from DO.

It is a public facing SaaS API which does not have much traffic in terms of requests, but would be catastrophic to be blackholed. So its that bad?

Regarding hardware failures- have never experienced any so far, but guess it's just a question of when then.


> It is a public facing SaaS API which does not have much traffic in terms of requests, but would be catastrophic to be blackholed. So its that bad?

Well, depends on whether you have people that don't like you. For them it can be rather easy to stage a DDoS against your server and take that server offline for some time.

> Regarding hardware failures- have never experienced any so far, but guess it's just a question of when then.

It has been happening to me much less often since they switched most of their portfolio over to "Enterprise Grade" disks. These days I tend to go with NVMe anyway so it has become less of an issue.


I thought part of their managed service was that they optimized / tuned your postgres db based on how you were using it. If that is true, then moving off of the managed service means you are tuning postgres yourself now.

Also want to throw in there that it is important to not only compare specs, but to also compare hardware. If DO has newer chips and faster RAM, then you will take a performance hit moving to the new provider even if the machine is beefier.


Pretty certain that DO tunes to broad usage performance optimization (all the easy, obvious performance wins), not dynamically per client to each client's usage.

Here's their pitch: easy setup & maintenance, scaling, daily backups, optional standby nodes & automated failover, fast reliable performance including SSDs, can run on the private network at DO and encrypts data at rest & in transit.


huh, when I used them in the past we had someone specifically look at our RDS and data usage and tune it.


They quote "We’ll handle setting up, backing up, and updating". I interpret that as literally the database itself, not the application specific nature of it—how it's used.

For example, I would be surprised if they noticed that your IOPS was high and you needed to upgrade the storage/disk components. (That would be cool if it's the type of thing they offer).




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

Search: