I'd go further, and say that most of the time, "SQLite is enough".
But, yes, PostgreSQL is all I ever use for anything that needs to be big. I ported a big old web app that had ScyllaDB, Elastic Search, Redis, and probably some other stuff I've forgotten. It got PostgreSQL+PostGIS (it's a mapping app), that's it. I'm sure there's some situation where it would be worth looking at all that other stuff, but it's ridiculous to build all that complexity in before you even have users.
Redis is basically free and nothing like the other tools you mentioned. Anytime I need a quick cache that will survive reboots it’s a winner. Agree on the other stuff though.
Yeah. Redis (valkey now for me mostly) is where I go for that extra oomph if the patterns make sense (or some level of scripting for dev work makes sense; the lua integrations is chef's kiss.).
Yes, for most projects, my path is SQLite -> PostgreSQL. For monolithic applications, SQLite is usually good enough. I've used OLTP + OLAP database setups before(SQL+ELK), but both data synchronization and operational overhead were very high. Before adopting such a solution, you really need to ask yourself: do you actually have that many users?
For database I think principle of medium fit is better than principle of least power. Flexibility for common circumstances is more important than making sure you made the most petite choice possible.
I agree, the reason why I had submitted this HN submission post was because I was getting way too deep into the weeds of new databases like surrealdb/tigerbeetle/scylladb etc.
which while are an interesting problem to think through because well, it makes me feel smarter knowing these databases. I still felt like postgresql was enough, (at best something like clickhouse or redis combined with postgresql might be more than enough for many things)
But the fact of the matter is that sometimes you don't even need postgresql. I actually just deploy sqlite apps in golang/rust, a website that I had made that is a single binary: https://mirror.forum
Sqlite is more than enough as well and there are a lot of people pushing sqlite above its weight as well (Turso and the likes)
but its nice knowing that Sqlite/postgresql are more than enough for many use cases. Both are really amazing for a lot of things :-D
Its amazing how we've for the most part atleast now simplified the architecture to have good options. Like using Sqlite and especially Postgresql in the start is a decision that you would rarely go wrong at. I personally feel like although I use sqlite a lot more in projects because i value the simplicity it gives but postgresql also holds a somewhat good relationship in my heart :-D
I recently built a site that aggregates top posts from various sources and am using both SQLite and Swift for my backend. Was a pleasant experience mostly.
I am primarily a mobile developer (I am the developer of Hack, hacker news app on iOS and android). While I have developed backends in rust and nodejs, I wanted to give swift a shot to see how it was. I used Vapor for the web server in swift. It was surprisingly pretty good experience and I am considering using it for my next project too.
But, yes, PostgreSQL is all I ever use for anything that needs to be big. I ported a big old web app that had ScyllaDB, Elastic Search, Redis, and probably some other stuff I've forgotten. It got PostgreSQL+PostGIS (it's a mapping app), that's it. I'm sure there's some situation where it would be worth looking at all that other stuff, but it's ridiculous to build all that complexity in before you even have users.