Lemmy

I'm not really sure that a K/V service is a more scalable option than Postgres for storing text posts and the like. If you're not performing complex queries or requiring microsecond latencies then Postgres doesn't require that much compute or memory.

People can get unnecessary scared of relational databases if they've had bad experiences with databases that are used poorly, but attempting to force relational data into a K/V can lead to the application layer essentially just doing a less efficient job of the same types of queries that the database would normally handle. Maybe there'll be some future need to offload post and comment bodies into object storage or something but that seems incredibly premature.

Object storage for pictrs is definitely a fantastic addition, though.

The 700MB are the postgres data or everything including the images?

I'm under the impression that text should be very cheap to store inside postgres.

The largest table holds data that is only needed by Lemmy briefly. There is a scheduled job to clear it... Every 6 months. There are active discussions on how best to handle this.

On my instance I've set a cronjob to delete everything but the most recent 100k rows of that table every hour.

It would be greater if it can also leverage IPFS. So we can have unique identifiers per media object and hence deduplication in a P2P network which in my opinion is more federvise affinitive. I have been thinking of making such an alternative media backend for a while.

There is a good writeup on how to do the migration here. I went through it myself since I host my tiny Lemmy instance on an AWS EC2 instance. It went pretty smoothly bu obviously larger instances will have to take a longer downtime to perform the migration.

Isn't it mostly pictures and movies taking up space, posts and comments that is just text doesn't take up much.

I would be fine with text is forever but pictures and movies are deleted after time.

AWS Postgres instances aren't that expensive, and they handle upgrades and backups for you.

That said, I'm interested in distributed storage, and maybe this fall/winter when I get some time off I'll try making a lemmy fork that's based on a distributed hash table. There are going to be a ton of issues (i.e. data will be immutable), but I have a few ideas on how to mitigate most of the issues I know about.

This is a great idea. Instances will need eventually to agree to common storage areas, even if they dont all allow the same content on their instance. That savings would be huge in the long run.

I worry that these sorts of things would end up turning the site into a popularity contest (or, well, more of a popularity contest than these sorts of sites already are. That being said, I'm quite proud of Lemmy, currently, as it appears to be resisting that). Also I'm not entirely sure how things like payed comment awards would work with everything being federated.

Yeah, no. No to paid features. That's how we ended up with reddit.

I'd be ok with something like a "donor" flair.

I think we could do some kind of profile badge if you donated. So it wouldn't influence the way people vote, only if you clicked on their profile will you see it.