Welches Backend ist am schnellsten — und warum die Antwort selten zählt.

Frag, welches Backend am schnellsten ist, und du bekommst ein Balkendiagramm. Zwölf Jahre lang kam dieses Diagramm von den TechEmpower Framework Benchmarks, die im März 2026 archiviert wurden — teils weil die Zahlen sich von allem entfernt hatten, was einer echten Anwendung ähnelt. Die ehrliche Antwort lautet: Die Sprachwahl ist fast nie der Grund, warum deine API langsam ist — dieser Leitfaden erklärt, was es ist.

Was die letzte Runde tatsächlich gemessen hat

Runde 23 der TechEmpower Framework Benchmarks, veröffentlicht im März 2025 und die letzte vor der Archivierung. Der Fortunes-Test ist der anwendungsnächste der Suite (Datenbanklesen, Sortieren, HTML-Rendering). Die absoluten Zahlen sind nicht mit früheren Runden vergleichbar: Microsoft stellte mitten im Projekt Server mit 56 Kernen an 40-Gbit-Netzwerk bereit, was netzwerkgebundene Ergebnisse um das 3- bis 4-Fache hob. Lies die Reihenfolge, nicht die Werte.

Warum der Benchmark-König keine Antwort mehr ist

Das TechEmpower-Repository wurde am 24. März 2026 archiviert, nach einer letzten Runde mit über 330 Framework-Implementierungen. Die vorangegangene Kritik ist der nützliche Teil: Die Testplattform hatte sich seit Jahren kaum verändert, Ergebnisse wurden vom Harness und nicht von den Frameworks begrenzt, und Einträge durften Low-Level-Optimierungen nutzen, die kein Team in ein echtes Produkt bringen würde. Ein Framework konnte das Diagramm mit Code anführen, den seine eigene Dokumentation nicht empfehlen würde.

Ein Nachfolgeprojekt, HttpArena, versucht dasselbe mit HTTP/2- und WebSocket-Unterstützung und absichtlich realistischen Implementierungen. Bis es vergleichbare Abdeckung hat, behandle jedes „schnellstes Backend 2026“-Diagramm als grobe Rangfolge von Obergrenzen, nicht als Vorhersage über deine Anwendung.

Wohin deine Antwortzeit wirklich geht

In einer typischen Business-API verbraucht die Sprache einstellige Millisekunden und alles andere den Rest. Eine Abfrage ohne Index, ein N+1-Muster, das 200 Abfragen auslöst, wo eine genügt hätte, ein synchroner Aufruf an einen Zahlungs- oder CRM-Anbieter, ein fehlender Cache auf einer Antwort, die sich stündlich ändert — jedes Einzelne davon kostet mehr als der gesamte Abstand zwischen dem schnellsten und dem langsamsten Stack in der Tabelle oben.

Deshalb enttäuscht es meist, einen langsamen Node-Service in Go neu zu schreiben. Wenn 480 ms einer 500-ms-Antwort eine Abfrage sind, die auf eine Datenbank wartet, ist das Verschieben der restlichen 20 ms auf 5 ms eine Verbesserung von 3 % für eine komplette Neuentwicklung. Die Abfrage zu reparieren sind 90 % für einen Nachmittag.

Was wir tatsächlich wählen — und warum

Node.js mit TypeScript ist unser Standard, überwiegend aus einem Grund, der nichts mit Performance zu tun hat: Es ist dieselbe Sprache wie das Next.js-Frontend, also werden Typen, Validierungslogik und Hilfsfunktionen geteilt statt doppelt implementiert und von Hand synchron gehalten. Für I/O-gebundene Arbeit — also die meiste Unternehmenssoftware — passt die Event-Loop wirklich gut, und die Tabelle oben misst Express, nicht die schnelleren Runtimes, die es inzwischen im selben Ökosystem gibt.

Zu Go greifen wir, wenn ein Service viele Tausend gleichzeitige Verbindungen günstig halten muss, oder wenn ein einzelnes kleines Binary mit vorhersagbarem Speicher operativ wertvoll ist. Python verdient seinen Platz überall, wo Machine Learning oder Daten-Tooling im Spiel ist, weil die Bibliotheken dort sind und nichts anderes nahekommt. Java ist die richtige Antwort, wenn es schon der Hausstack ist und ein Team dafür existiert. Rust empfehlen wir selten und gezielt: dauerhafter CPU-Durchsatz, bei dem die Hosting-Rechnung mit der Effizienz skaliert.

Wann die Sprache wirklich der Engpass ist

Das kommt vor. Echtzeitsysteme mit Zehntausenden dauerhaften Verbindungen, CPU-Arbeit pro Anfrage wie Bild- oder Videoverarbeitung, hochfrequente Datenaufnahme, oder Workloads, bei denen Rechenkosten eine relevante Position in der Bilanz sind — dort ist die Effizienz der Runtime eine betriebswirtschaftliche Zahl, keine Vorliebe.

Das Erkennungsmerkmal ist Messung, nicht Intuition. Zeigt das Profiling CPU-Sättigung im eigenen Code statt Wartezeit auf andere Systeme, zählt die Sprache. Sonst hast du ein Datenbank-, Caching- oder Architekturproblem im Kostüm eines Sprachproblems.

Die Kriterien, die rohe Geschwindigkeit schlagen

Wer pflegt das in drei Jahren, und kannst du diese Leute einstellen. Wie reif die Bibliotheken für deine konkreten Integrationen sind. Wie schnell ein Fix ausgeliefert wird, wenn morgens um 9 etwas bricht. Was Hosting bei deinem tatsächlichen Traffic kostet, nicht bei 600.000 Anfragen pro Sekunde. Ein Stack, der in einem synthetischen Benchmark 4-mal langsamer und in der Änderung 2-mal schneller ist, ist für fast jede Geschäftsanwendung die bessere wirtschaftliche Wahl.

„Schnell genug“ ist ein echtes Engineering-Ziel. Definier es — etwa 200 ms im 95. Perzentil unter erwarteter Last — und wähl dann den Stack, mit dem dein Team es weiter erreicht.

Quellen

Benchmark-Zahlen und die Archivierungs-Chronologie stammen hieraus, geprüft im Juli 2026.

• TechEmpower Framework Benchmarks — Runde 23 ↗

  Letzte veröffentlichte Runde des Projekts mit über 330 Framework-Implementierungen über die Tests Plaintext, JSON, Single-Query, Multi-Query, Fortunes und Updates.

• TechEmpower — Ankündigung von Runde 23 ↗

  Veröffentlicht am 17. März 2025. Dokumentiert den Hardwarewechsel — HPE ProLiant DL360 Gen10 Plus, Xeon Gold 6330 mit 56 Kernen, Mellanox 40 Gbit — und den daraus folgenden 3- bis 4-fachen Sprung bei netzwerkgebundenen Ergebnissen.

• DEV — TechEmpower Framework Benchmarks are now archived: what's next? ↗

  Hält die Archivierung am 24. März 2026 fest, die Kritik an Stagnation und unrealistischen Optimierungen, sowie HttpArena als vorgeschlagenen Nachfolger.