Warum Neleto auf Rust läuft (und die Benchmarks, die es belegen)

Wenn Leute fragen, warum ein kleines CMS-Startup sein Backend in Rust geschrieben hat, ist die einfache Antwort „Geschwindigkeit". Das stimmt, aber es ist nicht die ganze Geschichte — und es überspringt die Teile, die uns tatsächlich Zeit gekostet haben. Hier also die ehrliche Version, mit echten Zahlen statt Marketing-Adjektiven.

Die Entscheidung

Die meisten CMS-Plattformen basieren auf PHP, Node oder Python. Das sind völlig legitime Entscheidungen. Im Frontend nutzen wir selbst Node und TypeScript. Aber für den Teil von Neleto, der die schwere Arbeit macht — Content ausliefern, Seiten rendern, API-Anfragen verarbeiten — wollten wir etwas, das von Haus aus schnell ist, nicht schnell nach sechs Monaten Profiling und Caching-Workarounds.

Das Argument für Rust war simpel: vorhersehbare Performance, geringer Speicherverbrauch und ein Compiler, der eine ganze Kategorie von Bugs gar nicht erst in die Produktion lässt. Der Preis war ebenso simpel: Es ist schwerer zu schreiben, langsamer zu prototypen, und der Talentpool ist kleiner. Wir sind mit beidem im Kopf reingegangen.

Die Benchmarks

Diese stammen aus unserer eigenen Staging-Umgebung auf einer einzelnen Hetzner-CX22-Instanz (2 vCPU, 4 GB RAM, Region Deutschland). Gleiche Hardware, gleicher Content, gleicher Test. Wir haben Time-to-First-Byte und Requests pro Sekunde unter Last mit wrk bei 50 gleichzeitigen Verbindungen über 30 Sekunden gemessen.

*Der PHP-Vergleich ist eine Standardinstallation eines beliebten Open-Source-CMS auf derselben Hardware, ohne aggressives Tuning. Mit Caching-Plugins und CDNs sieht das anders aus — und genau das ist der Punkt. Die Rust-Zahlen sind das, was du bekommst, bevor du ein CDN hinzufügst, nicht danach.

Die Speicher-Zahl ist die, die für unsere Wirtschaftlichkeit am meisten zählt. Bei 78 MB unter Last können wir viele Kundenseiten auf einer einzigen Maschine betreiben. Das ist ein großer Teil davon, warum wir 24 €/Monat verlangen können, ohne dabei draufzuzahlen.

Wo Rust sich wirklich ausgezahlt hat

Konkret an drei Stellen:

Seitenrendering. Neleto rendert von Haus aus, wir schicken also nicht bloß JSON an das Frontend von jemand anderem. Die Template-Engine kompiliert zu nativem Code, und man merkt es — diese 11 ms gecachte TTFB sind der Unterschied zwischen einer Seite, die sich sofort anfühlt, und einer, die sich „okay" anfühlt.

Nebenläufigkeit ohne Drama. Die Async-Runtime bewältigt tausende gleichzeitige Verbindungen, ohne dass wir Worker-Pools von Hand tunen müssen. Während des agentischen Traffic-Anstiegs, über den wir kürzlich geschrieben haben, hat das Backend nicht mit der Wimper gezuckt. Bots, die die API hämmern, sehen für Rust genauso aus wie ein Ansturm von Menschen.

Der Compiler hat echte Bugs abgefangen. Schwer in Zahlen zu fassen, aber die Zahl der „Null-Reference in der Produktion um 2 Uhr nachts"-Vorfälle seit dem Launch ist null. Ein Teil davon ist Glück. Ein großer Teil ist der Borrow-Checker, der uns anschreit, bevor wir ausliefern.

Wo es wehgetan hat (der ehrliche Teil)

Build in Public heißt, auch die blauen Flecken zu zeigen.

Die Entwicklung war am Anfang langsamer. Features, die in Node einen Tag gekostet hätten, brauchten zwei oder drei, während wir mit dem Borrow-Checker gerungen und das Ökosystem gelernt haben. Unser erster Monat echter Geschwindigkeit kam erst, als wir ein paar Muster verinnerlicht hatten.

Einstellungen sind schwerer. Es gibt weniger Rust-Entwickler als PHP- oder JS-Entwickler, und die guten kennen ihren Wert. Für ein bootstrapped Team ist das eine echte Einschränkung, die wir jedes Mal spüren, wenn wir übers Wachsen nachdenken.

Manche Bibliotheken sind noch jung. Ein paar Dinge, die in der Node-Welt nur ein npm install entfernt sind, mussten wir uns selbst schreiben. Das ist Zeit, die wir nicht in Features für Kunden gesteckt haben.

Würden wir uns wieder für Rust entscheiden? Ja — aber nur, weil Performance und Infrastrukturkosten der Kern unseres Versprechens sind. Wenn wir ein schnelles MVP bauen würden, um eine Idee zu testen, hätten wir zu etwas gegriffen, das sich schneller prototypen lässt. Das richtige Werkzeug hängt davon ab, worauf du optimierst — und wir haben auf das optimiert, was Kunden bei jedem Seitenaufruf und wir bei jeder Serverrechnung spüren.

Was das für dich bedeutet

Wenn du ein CMS evaluierst, nimm „schnell" nicht auf Treu und Glauben — von uns oder von irgendjemandem. Mach den Test selbst. Wirf eine Seite in Neleto, richte einen Load-Tester darauf und schau dir die Zahlen auf genau der Hardware an, auf der du wirklich deployen würdest. Uns ist lieber, du vertraust dem Benchmark als dem Prospekt.

Und falls du Gründer bist und einen „langweiligen, schnell zu bauenden" Stack gegen einen „schwereren, aber schneller laufenden" abwägst: Es gibt keine universell richtige Antwort. Wir haben den härteren Weg gewählt, weil die Geschwindigkeit etwas ist, das unsere Kunden messen können. Sorge dafür, dass sich der Gewinn bei allem, was du wählst, auch für deine Kunden spürbar auszahlt.

Probier's selbst aus: Starte ein kostenloses Neleto-Projekt, veröffentliche eine Seite und benchmarke sie auf deiner eigenen Hardware. Wenn die Zahlen nicht besser sind als das, was du gerade betreibst, wollen wir davon hören.

Schnelle Websites. Einfacher Content. KI-nativ.