this post was submitted on 26 Jun 2026
24 points (100.0% liked)

General Programming Discussion

9942 readers
11 users here now

A general programming discussion community.

Rules:

  1. Be civil.
  2. Please start discussions that spark conversation

Other communities

Systems

Functional Programming

Also related

founded 7 years ago
MODERATORS
Cloak@lemmy.ml
Restioson@lemmy.ml
24
All you need is PostgreSQL (ebellani.github.io)
submitted 2 days ago by yogthos@lemmy.ml to c/programming@lemmy.ml
9 comments fedilink hide all child comments
top 9 comments
sorted by: hot top controversial new old
[–] dessalines@lemmy.ml 9 points 2 days ago (1 children)

This has pretty much been my philosophy with lemmy too.

Additional stores, caches, and other storage layers massively increase the complexity of your system. Suddenly you have 3+ places where the user could be getting the data from, and any of them might contain stale or incorrect data, that isn't linked or connected to primary source data.

Even after you add 2 of these layers, troubleshooting and finding problems is only solvable by people who know intimately how all of these things are connected. So I've always tried to keep these extra layers out of the lemmy codebase.

[–] yogthos@lemmy.ml 6 points 2 days ago

I've come to the same realization, the less moving pieces you have in your stack the better. Postgres can handle vast majority of persistence needs, and can even double up as a queue. So, there's really little justification adding another moving piece which you'll have to synchronize data with.

[–] davel@lemmy.ml 8 points 2 days ago (1 children)

*Except when all you need is SQLite.

[–] yogthos@lemmy.ml 5 points 2 days ago (1 children)

Yeah, it's amazing how good SQLite is nowadays. I find I use it for a lot of local apps I make for myself cause it's just good enough.

[–] dessalines@lemmy.ml 1 points 1 day ago (4 children)

SQLite is pretty incredible. I think it currently has even faster read performance than postgres.

The only reason to not use it, is if you have a write-heavy DB, or you need some of postgres's extra features.

[–] yogthos@lemmy.ml 3 points 1 day ago

there have been some really neat projects using it too like this one https://github.com/biokoda/actordb

[–] Count042@lemmy.ml 3 points 1 day ago

Or if you want too host it on NFS backed storage

[–] SocialistVibes01@lemmy.ml 3 points 1 day ago

That's my take as well, PostgreSQL is amazing, but in simpler DB schemes SQLite is undefeatable.

[–] gruf@lemmy.ml 2 points 1 day ago* (last edited 1 day ago)

we have more performance issues developing gotosocial with postgres than with sqlite. if we supported multinode deployments or horizontal scaling such that sqlite's concurrency got harder to reason-about I'm sure postgres would shine, but for a single process sqlite has been generally much faster and it hasn't required anywhere near as much prompting to get the query planner to behave as required.

i also think when people assume sqlite is better for simpler applications, they think smaller. but no, for the same 25+GB databases sqlite has mopped the floor with performance.

single-process multi-threaded sqlite is fantastic.