Every time I go to the piefed frontpage I'm blown away by how much more polished it is. It has all the bells and whistles that lemmy is sometimes missing.

Whats the catch? Why aren't we recommending everyone goes to piefed instead of lemmy?

App support is one thing I can think of.

you are viewing a single comment's thread
view the rest of the comments

[–] avidamoeba@lemmy.ca 39 points 6 months ago* (last edited 6 months ago) (28 children)

We have data on what it costs to run a sizeable instance of Lemmy and it's not a lot. How does Piefed compare? Anyone starting an instance who envisions it growing large has to contend with this question. Currently it seems it's got a bit under 1000 users across under 10 servers.

There are now sizeable communities run on Lemmy instances that are reinforced by network effects. There needs to be a significant reason for them to migrate. To that point, the collective project is building communities away from corporate power, not software. The software is a tool to facilitate that. Lemmy has worked well so far in this regard. If someone can show that Piefed can work better and not cost significantly more, it'll probably get adopted for new communities. If the difference is drastic, we may even see migrations from Lemmy.

[–] Sibshops@lemm.ee 11 points 6 months ago (8 children)

I second this. Lemmy is written in Rust where as piefed is written in Python. When it comes to running a high-performance webserver, Lemmy has the advantage.

[–] poVoq@slrpnk.net 18 points 6 months ago (4 children)

While theoretically true, the main bottleneck with Lemmy seems to be the database performance, so with both projects depending on PostgreSQL for that, I somewhat doubt that Piefed being written in Python will have much noticeable effect in reality.

[–] msage@programming.dev 4 points 6 months ago (1 children)

Postgres is so quick if you know how to use it...

[–] nickwitha_k@lemmy.sdf.org 2 points 6 months ago (1 children)

You don't even need to know how to use it very well, in my experience.

[–] msage@programming.dev 2 points 6 months ago

Really depends on many factors. If you have everything in RAM, almost nothing matters.

If your dataset outgrows the capacity, various things start to matter, based on your workload. Random reads need to have good indices (also writes with unique columns), OLAPs benefit from work_mem, >100M rows will need good partitioning, OLTP may even need some custom solutions if you need to keep a long history, but not for every transaction.

But even with >B of rows, Postgres can handle it with relative ease, if you know what you're doing. Usually even on a hardware you would consider absolutely inadequate (last year I migrated our company DB from MySQL to Postgres, and with even more data and more complex workflows we downsized our RAM by more than half).

load more comments (2 replies)

load more comments (5 replies)

load more comments (24 replies)