Hacker News Reader

Comment by chaz6 | Hacker News Reader

I am getting frustrated by the increase of hn articles about "self-hosting" yet the software described is reliant on a cloud service. To me, "self-hosting" means I can use it on my own computer, without a connection to the internet.

View on HN

This is the first time I've seen "selfhost" applied to something that restricts where I can load/run (this hippobase only lets me deploy in aws).

They seem to be highjacking the term

It’s also “organic” and “cruelty-free.”

thanks or pointing this out you two.

(saved me a click through!)

Maybe the mods can change the title? I mean the first word is easily.. and then to learn aws is required? haha

maybe hippobase - deploy aws hosted database systems

Agree, "self-hosting" suggests it being a tool, that creates and provisions databases on my own hardware-infrastructure and not on AWS.

How would you then call running a db on an EC2 instance or in a container as opposed to using a managed service like RDS?

Hosting

“AWS EC2 Hosted Database”

yeah I agree, it's a bit confusing. I meant "host in your cloud account" as opposed to "use a managed service". The vast majority of SaaS seems to be built cloud-first, it's quite easy to forget that other ways of hosting still exist.

Did you read what the service does? You probably don't need hourly snapshots backed up to S3, monitoring and replication if you are hosting MySQL on your local system. This looks to be more like setting up a managed service for production without paying the hosting provider for the extras.

To use this service you either have to pay Hippobase or AWS (excluding the 3-month free trial which would not be much use for production).

Right, but using Lightsail as an example to keep things simple, you're picking between scaling at 3x the cost of the server vs db service or a set $5 per database.

I would still trust the AWS service with something mission critical though. Hippobase might be good for stuff which isn't mission critical but otherwise wouldn't have anything the service offers because you don't want to throw the resources at.

The use case we had in mind initially was that teams often set up their production using Heroku db or RDS (naturally, because it's easy and reliable), and then when they need more environments they naturally do the same. But reliability often isn't that critical for dev environments. You lose your DB, so what? Just make a new one.

Then we realised that we could actually near production-grade reliability by doing backups, snapshots etc. So the choice is up to the user

Reply on news.ycombinator.com