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.
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.
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.
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.