Hacker News Reader

Comment by senttoschool | Hacker News Reader

>Making decisions about databases early results in needing to make a lot of secondary decisions about all sorts of things far earlier than you would if you just left it all in sqlite on one VM.

Like what? What could be easier than going to AWS, click a few things to spin up a Postgres instance, click a few more things to scale automatically without downtime, create read replicas, have automatic backups, one-click restore?

I feel like it's the opposite. Trying to put SQLite on a VM via Kubernetes will likely have a lot of secondary decisions that will make "scaling to millions" far harder and more expensive.

View on HN

> Like what? What could be easier than going to AWS, click a few things to spin up a Postgres instance, click a few more things to scale automatically without downtime, create read replicas, have automatic backups, one-click restore?

Not do that and not have to maintain that? Just a regular AWS instance with SQLite will be far easier to setup, with regular filesystem backup which is easier to manage and restore.

> Trying to put SQLite on a VM via Kubernetes will likely have a lot of secondary decisions that will make "scaling to millions" far harder and more expensive.

The issue is assuming that "scaling to millions" is a design goal from the start. For a lot of projects, the best-case-scenario does not require it. For another big set of them, they will never get to it. For the few that do, it's possible that the cost of maintaining the more complex solution while it isn't needed plus the cost of adapting over time (because, let's be honest, it's almost impossible to get the scaling solution right from the start) is more than the cost of just implementing the complex solution when it's actually needed.

>Not do that and not have to maintain that? Just a regular AWS instance with SQLite will be far easier to setup, with regular filesystem backup which is easier to manage and restore.

You'd have less maintenance using RDS than you would with an SQLite hosted on a VM.

>The issue is assuming that "scaling to millions" is a design goal from the start.

I was responding to the OP who said you can scale to "millions of revenue" on SQLite. This part is true. You could. But it'd be easier to do it on a managed Postgres instance.

> You'd have less maintenance using RDS than you would with an SQLite hosted on a VM.

Considering that the maintenance I need to do for SQLite databases is practically zero...

> I was responding to the OP who said you can scale to "millions of revenue" on SQLite.

Millions of revenue doesn't necessarily need a high performance database. You could have millions on a page that deals with less than one request per second.

>Considering that the maintenance I need to do for SQLite databases is practically zero...

I also do zero maintenance on AWS RDS. Didn't have to setup it up either. Just a few clicks, copy and paste connection string, done. No VM to configure. No SSL to configure. No backup to configure.

Two clicks for a read only replica. A few more clicks and I can have multi-node failover. You'd want a failover if you have "millions in revenue" no? How do you plan to set that up with SQLite on a VM?

If you're at millions of revenue and haven't made the switch to a more robust setup I'd have questions.

The question isn't about what you do when you get there the question is if you get there or if you flounder about deciding between self managed MySQL, postgress, rds, MongoDB, gcp, AWS or Azure.

>If you're at millions of revenue and haven't made the switch to a more robust setup I'd have questions.

Companies with more revenue than "millions" are still running AWS RDS.

https://aws.amazon.com/rds/customers/

I think you misread me or I didn't word it well enough.

I meant switch off sqllite by the time you're running a real business critical application off your db.

Reply on news.ycombinator.com