---
title: "Stefan Wintermeyer · 2026-09-08"
description: "AFAIK ist Mastodon im Kern eine Ruby on Rails Applikation. Das ORM wäre dann ActiveRecord. Eigentlich ist ActiveRecord nicht schlecht und generiert auch brauchbares SQL. Aber es kann natürlich nicht s"
url: https://vutuv.de/wintermeyer/posts/01a0808a-09c5-7049-8b9c-534064378ec2
type: post
schema_version: 3
generated_at: 2026-09-08T14:20:02Z
---

# Post by [Stefan Wintermeyer](https://vutuv.de/wintermeyer) · 2026-09-08

> In reply to a post by [@alvar@freude.social](https://freude.social/users/alvar/statuses/117231286402674628).
>
> Werfe einen Blick in das PostgrSQL-Log. In dem werden auch long-running-Queries protokolliert. Und was sehe ich da? #Mastodon macht:
> 
>  SELECT "tags".* FROM "tags" WHERE "tags"."id" IN ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, \[…\] $5272, $5273, $5274) AND "tags"."id" > $5275 ORDER BY "tags"."id" ASC LIMIT $5276
> 
> Heiliger Bimbam, 5276 Bind-Parameter. Wer baut sowas … – sieht nach irgendeinem gammeligem ORM aus.
> Ja, natürlich sind Bind-Parameter richtig und korrekt. Aber doch nicht über 5000! 
> 
> Die kommen doch garantiert auch aus der DB. SQL kann sowas wie:
> 
>  SELECT * FROM tags WHERE id IN (SELET tag_id FROM <wasauchimmer> WHERE <bedingung>) AND id > $1 ORDER BY id ASC LIMIT $2;
> 
> Allerdings riecht "id > $x" irgendwie auch nach einem schlechten Datenbank-Modell.

AFAIK ist Mastodon im Kern eine Ruby on Rails Applikation. Das ORM wäre dann ActiveRecord. Eigentlich ist ActiveRecord nicht schlecht und generiert auch brauchbares SQL. Aber es kann natürlich nicht suboptimale Programmierung ausbügeln. Das hier ist kein Framework oder ORM Problem. Da hat jemand beim Programmieren nicht bis ans Ende gedacht. 

Schaue Dir mal die https://abuuba.com Benchmark Vergleichswerte an. Bei Mastodon gibt es noch viel Optimierungspotential.

Tags: #performance, #sql, #Mastodon, #ActiveRecord, #Geschwindigkeit

Likes: 1 · Reposts: 0 · Bookmarks: 0 · Replies from other networks: 1 · Already counted in the numbers above.

Liked by: René Oelke

## Conversation (4)

#### [René Oelke](https://vutuv.de/reneoelke/posts/01a080bd-85ce-7c62-b98f-523ae120ae7a) · 2026-09-08

> In reply to a post by Stefan Wintermeyer.

@wintermeyer Eines der Optimierungspotentiale scheint wohl auch Storage und Caching zu sein. Ist das in abuuba anders oder sogar besser gelöst?

##### [Stefan Wintermeyer](https://vutuv.de/wintermeyer/posts/01a080c2-6b1c-7e87-b58b-41b4d6dcfeb9) · 2026-09-08

> In reply to a post by René Oelke.

Ich bin ja ein großer Fan vom Caching. Aber Caching funktioniert nur richtig gut, wenn die Grundlagen dahinter sauber geplant und programmiert wurden.

Mastodon hat diesbezüglich Raum für Verbesserungen.

abuuba hat es aber auch einfacher. Es ist immer einfacher Fehler anderer zu sehen und diese dann nicht zu wiederholen, als selbst auch von Null anzufangen.

#### [Stefan Wintermeyer](https://vutuv.de/wintermeyer/posts/01a080ef-7746-7789-9bdc-c4d97a2dbc5d) · 2026-09-08

> In reply to a post by Stefan Wintermeyer.

Ja, das kenne ich aus meinem beruflichen Alltag auch nur zu gut. Es mangelt oft an den Grundlagen. Wenn dann noch eine "Schicht" Caching drüber gelegt wird, dann wundert sich jeder, warum bei jeder zweiten Abfrage falsche Ergebnisse rauskommen.

## Replies from other networks (1)

### Alvar Freude (@alvar@freude.social)

@wintermeyer@vutuv.de ja, mastodon ist Ruby on Rails. Welches ORM verwendet wird weiß ich nicht. 

In Sachen SQL ist „siboptimale Programmierung“ leider Standard. Sehe ich sehr sehr häufig. Habe früher als Freiberufler u.a. PostgreSQL Performance-Tuning gemacht. Oft wurden noch nicht mal die Grundlagen beherrscht.

[View the original](https://freude.social/@alvar/117235343788928300)