Amen

I swear Postgres always has new features whenever I look at it again.

I was building a system for long running durable job queues with multiple workers and of course Postgres has a solution for that. You can do row-level locking in a transaction to "reserve" jobs for the duration of that transaction, and you can use SKIP LOCKED to skip over reserved jobs so workers don't block each other. There's also LISTEN and NOTIFY if you want pub/sub to track when jobs complete, for example.

Seems, at a cursory look, to be a pretty solid intro to PostgreSQL. As @Valmond@lemmy.dbzer0.com commented, people sleep on SQLite. I think a lot of people skip SQLite because they think they need more. Hell, just about all my personal uses are covered with GNU recutils.

I hate admining PostreSQL, and groan when some app I want to use requires it. Don't get me wrong: in a corp environment where someone else is responsible for backup/restore and permissions, pgsql > *. Tooling for it is great. It has every feature. But if I have to maintain it myself, I'll chose a single file to copy and back up every time: sqlite FTW.

Or SQLite for embedded systems, and a NoSQL for no-sql, and MariaDB for FOSS DB.

Did I forget anything?

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.

*Except when all you need is SQLite.