Live data from Hacker News

Digital Ocean Managed Databases

try.digitalocean.com

11–20 of 171 posts

Re: Digital Ocean Managed Databases

#12

I for one have always liked the simplicity of DO for hosting but I've never wanted to take on the full liability of self-rolling a DB server (and backups and replicas). So everything my company has I've put on heroku or azure. This has potential to be really significant as I'd wager there are a lot of folks in similar situations.

If you have a relatively small set of users, setting up your own database is usually as simple as setting it up locally and you won't need shards or anything. And setting up backups is as simple as adding a cron job that calls your backup shell script, which you can test separately. And by "small set of users", consider what SQLite's own website[1] says:

    Generally speaking, any site that gets fewer than 100K
    hits/day should work fine with SQLite. The 100K hits/day
    figure is a conservative estimate, not a hard upper bound.
    SQLite has been demonstrated to work with 10 times that
    amount of traffic.
If SQLite is able to comfortably handle 100k hits/day, I imagine that more "legitimate" databases can handle more traffic comfortably without needing to jump to scale horizontally.

[1] https://www.sqlite.org/whentouse.html under "Websites" section

Re: Digital Ocean Managed Databases

#13

I for one have always liked the simplicity of DO for hosting but I've never wanted to take on the full liability of self-rolling a DB server (and backups and replicas). So everything my company has I've put on heroku or azure. This has potential to be really significant as I'd wager there are a lot of folks in similar situations.

I am definitely on that particular boat. I'll add one more point:

- Not very willing to setup DBs for several projects both paid and hobby because it's a fixed time sink. And before anybody tells me "but with this script it can take 2 minutes!" please don't forget that to learn to use your magical script I have to learn a few other things beforehand. (Although admittedly that's most likely a small time investment.)

Re: Digital Ocean Managed Databases

#14
Just started using the new Kubernetes offering on Digital Ocean. Still in Beta but works pretty good. If this is a sign for how they will do databases, I'm all ears. Add CI/CD and you have a Heroku competitor.

Re: Digital Ocean Managed Databases

#16
very interesting. With this and the new DO kubernetes offering (if both are reliable), DO could be a compelling option for postgres-based kubernetes clusters baseload - circa half the price of google cloud.

All the other stuff you need like logs and monitoring can be installed with helm charts.

Re: Digital Ocean Managed Databases

#17

I for one have always liked the simplicity of DO for hosting but I've never wanted to take on the full liability of self-rolling a DB server (and backups and replicas). So everything my company has I've put on heroku or azure. This has potential to be really significant as I'd wager there are a lot of folks in similar situations.

If you have a relatively small set of users, setting up your own database is usually as simple as setting it up locally and you won't need shards or anything. And setting up backups is as simple as adding a cron job that calls your backup shell script, which you can test separately. And by "small set of users", consider what SQLite's own website[1] says: Generally speaking, any site that gets fewer than 100K hits/day…

The real benefit to having someone else manage your DB is that it eliminates the "unknown unknowns." I don't want to spend the requisite time becoming an expert DB sysadmin--I'd rather let someone else do it so that I can sleep at night. Also, databases are in a different category of risk. Misconfigure an nginx config? No big deal, fix it and move on. Set up your database incorrectly, resulting in data loss down the road? Could be game over.

Re: Digital Ocean Managed Databases

#20

I for one have always liked the simplicity of DO for hosting but I've never wanted to take on the full liability of self-rolling a DB server (and backups and replicas). So everything my company has I've put on heroku or azure. This has potential to be really significant as I'd wager there are a lot of folks in similar situations.

If you have a relatively small set of users, setting up your own database is usually as simple as setting it up locally and you won't need shards or anything. And setting up backups is as simple as adding a cron job that calls your backup shell script, which you can test separately. And by "small set of users", consider what SQLite's own website[1] says: Generally speaking, any site that gets fewer than 100K hits/day…

Agree sqlite is great and >80% of websites will probably run fine on it, but 100K hits/day is pretty vague, does that mean 1 hit/sec or 3 hits/sec during peak time, etc...?
Post reply on HN