Hacker News Reader

Comment by victorbjorklund | Hacker News Reader

99,99% of apps dont need more than one app server. You can serve a lot of traffic on the larges instances.

For sure downtime is easier with kubernete etc but again overkill for 99,99% of apps.

Serving users is one thing. Then you want to run some interactive analytics or cronjobs for cleanup etc on the db. Even if the load can manage it, how would the admin jobs connect to the database. I’ve never seen a db with only one client. There is always some auxiliary thing, even when you don’t consider yourself a microservice shop.

For analytics the solution is very simple. Just copy the database and run the queries on the copy.

agree - with SQLite and DuckDB I've really switched my mindset from one perfect, pristine DB to multiple copies and a medallion architecture that looks more like participation ribbons for everyone! The resources required are so cheap & lightweight when you avoid the big "BI focused" tech stacks.

you can also scale out across unlimited tiny servers, because the entire stack is so lightweight and cheap. This will also force you to focus on devops, which otherwise can become a grind with this approach. The only challenge is when you have cross-DB concerns, either data or clients.

Right, but if your goal is to have a lot of users (and minimal downtime), there's no point in putting a big avoidable obstacle in your path when the alternative is just as easy.

If your goal is to serve billions of users you should probably use cassandra etc. Why limit yourself to postgres if your goal is to have a billion users online at the same time?

Because cassandra isn't easy to set up and has all kinds of tradeoffs on consistency, transactions, et al compared to an SQL db.

On the other side, why not just store everything in memory and flush to a local json file if you won't have any users? sqlite is overkill!

your goal should be to solve this problem when you have a million or 10M concurrent users. YAGNI

Reply on news.ycombinator.com