Good morning, everyone:
After months of troubleshooting various performance issues, we’re pleased to announce that all of the outstanding back-end issues we are aware of are fixed. You should no longer receive errors on browsing user profiles, and posts should load much faster.
If you’re not technical or interested in the gritty details, you can stop reading, now, in the knowledge that everything should now work as expected. For those of you who are technical, the problems were caused by two things. First, a lack of indexes on the users and posts tables. Analysing logs revealed some database queries were taking upwards of 8 seconds, especially when loading user profiles. If you’ve landed here from Google, because lemmy-ui is giving the unhelpful message “an error has occurred on the server” without actually showing you the error, and you’re seeing enormous queries referencing dullbananas’s or i_love_jesus in your logs, get into your postgresql database and add some indexes:
CREATE INDEX idx_post_aggregates_creator ON post_aggregates (creator_id);
CREATE INDEX idx_post_aggregates_scaled_rank ON post_aggregates (scaled_rank);
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_post_saved_person_post ON post_saved (person_id, post_id);
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_community_moderator_community_person ON community_moderator (community_id, person_id);
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_local_user_admin ON local_user (admin);
Second, be careful when increasing your shared memory size in docker. If you have shm_size specified as “48 gb” or “48gb” in your docker compose, your shared memory will not increase, and you won’t get an error message of any kind. Shm_size must be “48g”, no space, and no b. For some bonus fun, shm_size only updates if you recreate the entire docker image. Restarting is not enough! You should always use df on the docker you’re working with, to insure /dev/shm is actually the size you think it is. Because it probably isn’t!
Happy holidays, everyone. Here’s to a 2026 of stability and new features.


Bonus third fix: If you notice that your pict-rs is using a lot of CPU or doing an unreasonable amount of IO, convert from using SLED (the default image repo) to using postgresql. The documentation for doing this is provided in the pict-rs crate.