>Pleroma gets crippled by simply getting accessed too much

Pleroma does what Mastodont

@matrix if you saw my logs you'd see how fast it was and how many there were.

@matrix but yeah I don't really know why it's not so bad for mastodon comparably

@sun What seems to be the bottleneck?
My uneducated guess is that it's just bad DB design because I never saw a DB bottleneck with Mastodon.
What I usually saw was just requests not getting fulfilled fast enough because Ruby is slow and that was always solved by more processes and more CPU and RAM. SPW is on a dedi right?

@sun I think only large instances like Pawoo and MatSoc probably need a secondary read only db, while I remember p having to deploy one for FSE

@matrix @sun It doesn't help that Pleroma was probably never designed to withstand the traffic it does now. It was meant to be a straightforward AP implementation and the DB reflects that. It doesn't attempt a bunch of normalization of objects
into colums, it shoves the whole object into a jsonb column and calls it a day.

The DB schema is quite performant anyway, the sizes of indexes are the issues usually.

@phnt @matrix @sun pleroma was also designed when the fedi network was smaller and you were running it on a rpi or some shit and it's clear the devs are pandering to the crowd that will just run a pds in the bsky gated community anyhow

@PurpCat @phnt @sun Isn't Mastodon older?

@matrix @PurpCat @phnt mastodon was built from the ground up for scaling, you can argue about how good it is but the attempt was made

@sun @PurpCat @phnt Pleroma should ideally be better at scaling because of Erlang

@matrix @sun @PurpCat feld had an almost working prototype for multiple nodes at some point I think. There was an issue with Cachex I think and that was it.

@phnt @PurpCat @matrix @sun oh yeah we just need to replace Cachex and it's not hard, I just ended up moving and other priorities stacked up

@feld @PurpCat @phnt @sun why not Redis/Valkey? Is it to minimize dependencies?