5 ms·
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
by SwellJoe 4mo ago
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.
- busymom0 4mo agoI 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. https://limereader.com/ https://limereader.com/
- green_wheel 4mo agoWhy'd you go with swift for the backend?
- busymom0 4mo agoI 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.
- brianwawok 4mo agoRedis 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.
- zxexz 4mo agoYeah. 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.).
- threatofrain 4mo agoFor 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.
- ammo1662 4mo agoYes, 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?
- Imustaskforhelp 4mo agoI 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 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