Anna hat sechs Monate Rust gelernt. Die Sprache fasziniert sie: kein Garbage Collector, Memory Safety ohne Laufzeitkosten, ein Typsystem, das Fehler vor dem Kompilieren findet. Dann durchsucht sie 20 Backend-Stellenanzeigen in Berlin. Java: acht Treffer. Python: sechs. TypeScript: vier. Go: einer. Rust: einer, und der verlangt fünf Jahre Berufserfahrung in Systems Programming.
Annas Geschichte zeigt ein Problem, das viele Einsteiger betrifft: Die technisch eleganteste Sprache ist nicht automatisch die mit den meisten Jobs. Dieser zweite Teil der Serie sortiert die Backend-Technologielandschaft nach dem, was auf dem Arbeitsmarkt wirklich zählt. Mit aktuellen Zahlen vom Februar 2026, ohne Hype und ohne Abkürzungen.
Welche Sprachen dominieren den Backend-Markt?
Die Frage nach der richtigen Programmiersprache beschäftigt Backend-Einsteiger mehr als jede andere, und gleichzeitig ist sie die am meisten überbewertete: Ein erfahrener Entwickler kann in sechs Monaten von Python zu Java wechseln, aber nicht von fehlenden SQL-Kenntnissen zu tiefem Datenbankverständnis. Trotzdem muss man irgendwo anfangen, und die Arbeitsmarktdaten zeigen klare Präferenzen.
Python führt den TIOBE-Index im Februar 2026 mit 21,81 Prozent Marktanteil [1]. Das überrascht auf den ersten Blick, weil Python als interpretierte Sprache langsamer ist als kompilierte Alternativen. Erklären lässt sich der Erfolg durch die Breite des Angebots: Web-Backends mit Django und FastAPI, Machine-Learning-Pipelines, Automatisierungsskripte, Datenanalyse. Kein anderer Tech-Stack deckt so viele Anwendungsfälle ab. Gerade der KI-Boom der letzten zwei Jahre hat Python noch weiter nach vorn geschoben, weil TensorFlow, PyTorch und die meisten LLM-Frameworks Python als primäre Schnittstelle nutzen.
Java und Kotlin beherrschen den Enterprise-Bereich. Großbanken, Versicherungen, Automobilkonzerne: Wo langlebige Systeme mit hohen Zuverlässigkeitsanforderungen stehen, läuft Java. Zalando hat Kotlin in seinem Tech-Radar von „Trial“ auf „Adopt“ hochgestuft und innerhalb eines Jahres über 100 neue Kotlin-Anwendungen geschrieben. Die ING setzt im Backend auf Java und Kotlin mit Spring Boot, die Deutsche Bank betreibt ihre Zahlungssysteme auf Spring Boot. Am deutschen Stellenmarkt liegen Java und Python mit jeweils rund 11.000 Ausschreibungen nahezu gleichauf. Berlin stellt rund 37 Prozent aller Software-Engineering-Stellen in Deutschland, gefolgt von München und Hamburg.
TypeScript mit Node.js bildet die dritte Säule. Startups und Unternehmen, die Frontend und Backend mit derselben Sprache abdecken wollen, greifen zu Node.js. Produktivität ist hoch. Der Talentpool überschneidet sich mit dem Frontend. Meine Einschätzung: Für Fullstack-Teams die pragmatischste Wahl, für reine Backend-Teams nicht immer die beste.
Gehälter variieren regional erheblich: Stuttgart und München zahlen Backend-Entwicklern im Schnitt zwischen 51.000 und 71.000 Euro jährlich, Berlin liegt bei 47.000 bis 65.000 Euro, bietet dafür aber die mit Abstand größte Auswahl an Stellen, von Startups in Kreuzberg bis zu den Berliner Büros internationaler Konzerne wie Amazon und Google.
C# mit .NET verdient mehr Aufmerksamkeit, als es in Entwicklerforen bekommt. Tausende Mittelstandsunternehmen und Konzerne in Deutschland arbeiten mit .NET-Backends. CHECK24 setzt unter anderem auf C#, viele Industrieunternehmen nutzen .NET für interne Systeme. Performance von .NET 8 ist konkurrenzfähig mit Go und Java, das Tooling mit Visual Studio und JetBrains Rider ausgereift. Wer in den deutschen Enterprise-Bereich will, sollte C# nicht ignorieren.
PHP ist nicht tot. Das klingt nach Provokation, ist aber Fakt: Laravel und Symfony treiben einen erheblichen Teil des deutschsprachigen Webs an. WordPress allein läuft auf 43 Prozent aller Websites weltweit. Im Mittelstand, bei Agenturen und im E-Commerce bleibt PHP-Know-how gefragt. Niemand muss PHP als erste Sprache lernen. Aber die Existenz dieser Jobs leugnen wäre unehrlich.
Wo stehen Go und Rust?
Go hat sich für Cloud-native Entwicklung etabliert. Docker, Kubernetes, Terraform, Prometheus: alles Go. Das sagt viel. Kompiliert wird zu einem einzigen Binary ohne Abhängigkeiten, gestartet in Millisekunden, eingebaute Concurrency über Goroutines. Für Microservices und CLI-Tools eine exzellente Wahl. SAP listet Go neben Java und Python in seinen Backend-Stellenausschreibungen. Insgesamt konzentrieren sich die Stellenangebote auf Cloud-Anbieter, DevOps-Tooling und FinTech.
Rust bleibt eine Nische. Aber eine wachsende. Tatsächlich löst Rust echte Probleme: Memory Safety ohne Garbage Collection, Geschwindigkeit auf C-Niveau. Laut Stack Overflow 2025 ist Rust seit Jahren die „meistgeschätzte“ Sprache unter Entwicklern (72 Prozent Admiration Score), wird aber nur von einer kleinen Minderheit beruflich eingesetzt [2]. Lernkurve: steil. Arbeitsmarkt: schmal. Für Einsteiger ist Rust 2026 keine sinnvolle erste Sprache. Für erfahrene Entwickler, die in Systems Programming oder Performance-kritische Dienste wechseln wollen, lohnt sich der Aufwand.
Am Stellenmarkt zeigt sich eine klare Hierarchie: Java- und Python-Entwickler finden die meisten offenen Positionen, während Go- und Rust-Spezialisten zwar höhere Gehälter erzielen können, aber deutlich weniger Stellen vorfinden. Nachfrage bestimmt den Einstieg, nicht Eleganz.
Frameworks: Welches passt zu welchem Projekt?
Frameworks bestimmen den Arbeitsalltag stärker als die Programmiersprache. Ein Spring-Boot-Projekt fühlt sich fundamental anders an als ein Express.js-Service. Drei Frameworks dominieren, ein viertes holt auf. Welches passt, hängt vom Projekttyp ab.
Express.js bleibt das meistgenutzte Backend-Framework weltweit. Minimalistisch, flexibel, riesige Auswahl an Middleware. Kehrseite: Express gibt wenig Struktur vor, weshalb große Projekte ohne Konventionen schnell unübersichtlich werden. NestJS adressiert genau dieses Problem mit einem opinionated Framework auf Express-Basis, das Dependency Injection und modulare Architektur mitbringt. Für ein Startup, das mit drei Entwicklern eine API hochziehen will, bleibt Express die schnellste Route zum Prototyp, aber der Code wird bei wachsender Teamgröße zum Problem, wenn niemand vorher Konventionen für Ordnerstruktur, Error Handling und Middleware-Reihenfolge festgelegt hat.
Spring Boot dominiert die Java-Welt seit über einem Jahrzehnt. Konfiguration über Convention, eingebetteter Server, eine riesige Bandbreite an Integrationen. Für Enterprise-Anwendungen in Konzernen gibt es kaum eine Alternative. Steile Lernkurve, ja. Aber die Investition zahlt sich in großen, langlebigen Projekten aus.
FastAPI ist der Aufsteiger im Python-Umfeld. Automatische API-Dokumentation mit OpenAPI, Typ-Validierung über Pydantic, asynchrone Unterstützung nativ eingebaut. Gegenüber Django REST Framework bietet FastAPI deutlich bessere Performance und modernere Entwicklungsmuster. Django selbst hat seine Berechtigung: Wer ein Admin-Interface, ein ORM und User-Management out of the box braucht, fährt mit Django schneller. Für reine APIs ohne Frontend-Komponente gewinnt FastAPI. Für Full-Stack-Anwendungen mit Datenbankadministration gewinnt Django. Konkretes Beispiel: Wer eine REST-API für eine Mobile App baut, die Daten aus einer PostgreSQL-Datenbank liefert und 500 Requests pro Sekunde verarbeiten muss, ist mit FastAPI in wenigen Stunden produktiv, während Django für dieses Szenario unnötigen Overhead mitbringt.
Bei Go ist Gin das Standardframework. Minimalistisch wie Express, aber mit der Typsicherheit und Performance von Go. Für Teams, die bereits Go einsetzen, die logische Wahl.
Meine Faustregel: Prototyp oder API-Service → FastAPI. Enterprise-Projekt mit Java-Team → Spring Boot. Fullstack JavaScript → Express oder NestJS. Hochperformanter Microservice → Gin oder reines Go. Am Ende schlägt die Sprache des bestehenden Teams jede theoretische Benchmark.
Welche Datenbanken braucht man wirklich?
PostgreSQL hat die Datenbankwelt konsolidiert. Rund 55 Prozent der Entwickler in der Stack Overflow Survey 2025 nutzen PostgreSQL, mit deutlichem Abstand vor MySQL (40 Prozent) und SQL Server (30 Prozent) [3]. Im DB-Engines Ranking behauptet PostgreSQL seit Jahren Platz vier hinter Oracle, MySQL und SQL Server, zeigt aber den stärksten Wachstumstrend aller Datenbanken [8]. Vielseitigkeit erklärt diesen Vorsprung: relationale Abfragen, JSON-Dokumente, Volltextsuche, Vektoren für KI-Anwendungen per pgvector.
PostgreSQL 18 erschien im September 2025 und bringt einen echten Meilenstein: asynchrone I/O [11]. Sequenzielle Scans und Vacuum-Operationen laufen bis zu dreimal schneller als in Version 17. Dazu kommen native UUIDv7-Generierung und OAuth-Authentifizierung. Relevant ist das, weil PostgreSQL damit Performance-Argumente entkäftet, die bisher für spezialisierte Lösungen sprachen.
MySQL steht vor einem Wendepunkt. Version 8.0 erreicht im April 2026 das End of Life [12]. Nachfolger MySQL 8.4 LTS erschien bereits im April 2024 mit Support bis 2032. Trotzdem: Für Neuprojekte gibt es 2026 kaum noch Gründe, MySQL statt PostgreSQL zu wählen. Mehr Features, bessere Standardkonformität, aktivere Community. MySQL bleibt relevant im älteren Webhosting-Bereich und überall dort, wo LAMP-Stacks laufen. Wer ein bestehendes WordPress- oder Magento-System wartet, kommt an MySQL nicht vorbei, aber für jedes neue Projekt, bei dem man die Wahl hat, spricht die Summe aus Features, Community-Größe und Zukunftssicherheit klar für PostgreSQL.
Hat NoSQL wirklich SQL abgelöst?
Nein. Die meisten Anwendungen brauchen Relationen zwischen Daten, Transaktionen und komplexe Abfragen. Genau dafür sind SQL-Datenbanken gebaut.
MongoDB, Redis und DynamoDB haben ihre Berechtigung für spezifische Anwendungsfälle. Redis als In-Memory-Cache und Session-Store ist nahezu allgegenwärtig. Aber die Landschaft hat sich verschoben. Redis wechselte im März 2024 von der BSD-Lizenz auf ein proprietäres Modell. Die Reaktion kam schnell: Die Linux Foundation startete mit Valkey einen Open-Source-Fork, unterstützt von AWS, Google Cloud und über 50 weiteren Unternehmen. Version 9.0 vom Oktober 2025 erreicht über eine Milliarde Requests pro Sekunde im Cluster-Betrieb [9]. Wer heute Redis-Expertise aufbaut, sollte Valkey im Blick behalten. AWS bietet Valkey-basierte ElastiCache-Services bereits rund 30 Prozent günstiger an als die Redis-Varianten, was für kostenorientierte Projekte ein gewichtiges Argument darstellt.
Meine Empfehlung für Einsteiger: PostgreSQL gründlich lernen, Redis oder Valkey als Cache verstehen, den Rest nach Bedarf.
Vektor-Datenbanken und NewSQL als neue Spieler
Zwei Trends verdienen Beachtung. Erstens: Vektor-Datenbanken wie Pinecone, Weaviate und Qdrant wachsen durch KI-Anwendungen, die Ähnlichkeitssuchen auf Embeddings benötigen. pgvector integriert diese Fähigkeit direkt in PostgreSQL. Für ein Startup, das eine semantische Suche braucht, reicht oft eine PostgreSQL-Instanz mit pgvector-Erweiterung statt einer separaten Infrastruktur. Erst bei Millionen von Vektoren und Echtzeit-Anforderungen lohnt sich eine dedizierte Lösung.
Zweitens: NewSQL-Datenbanken wie CockroachDB und TiDB versprechen die Skalierbarkeit von NoSQL mit der Konsistenz von SQL. Für global verteilte Anwendungen interessant, für die meisten Projekte aber Over-Engineering. Die allermeisten Webanwendungen kommen mit einer einzelnen PostgreSQL-Instanz und Read Replicas aus. OpenAI betreibt ChatGPT für 800 Millionen Nutzer auf genau diesem Modell [7].
Cloud: Pflicht oder Kür?
Ohne Cloud-Kenntnisse läuft im Backend-Bereich 2026 fast nichts mehr. Das ist keine Übertreibung. AWS führt den Markt mit 28 Prozent Anteil, gefolgt von Azure (21 Prozent) und Google Cloud (14 Prozent) [4]. Managed Databases, Message Queues, Object Storage, Serverless Functions: Diese Dienste gehören zum Standardrepertoire. Wer sich als Backend-Entwickler bewirbt, wird in neun von zehn Stellenanzeigen auf mindestens einen der drei großen Anbieter als gewünschte Kompetenz stoßen, häufig kombiniert mit der Erwartung, Infrastructure as Code mit Terraform oder Pulumi umsetzen zu können.
In Deutschland kommt ein Faktor hinzu, den US-zentrische Ratgeber gern übersehen: Datensouveränität. Unternehmen in regulierten Branchen wie Gesundheitswesen, Finanzsektor und öffentlicher Verwaltung brauchen Rechenzentren in der EU, idealerweise in Deutschland. IONOS, OVH und Hetzner bieten hier Alternativen zu den US-Hyperscalern. Gaia-X als europäische Cloud-Initiative existiert zwar, hat aber bisher wenig marktreife Produkte hervorgebracht. Für datensensible Projekte im DACH-Raum lohnt sich trotzdem ein Blick auf europäische Anbieter. Hetzner verdient besondere Erwähnung: Cloud-Server zu einem Bruchteil der AWS-Preise, Rechenzentren in Nürnberg und Falkenstein, volle DSGVO-Konformität. Für kleine Teams ohne globalen Footprint oft der kosteneffizienteste Einstieg.
Kubernetes hat die Container-Orchestrierung gewonnen. 93 Prozent der in der CNCF-Umfrage 2024 befragten Unternehmen nutzen oder evaluieren Kubernetes [5]. Für Backend-Entwickler bedeutet das: Docker-Container bauen, Kubernetes-Manifeste schreiben oder Helm-Charts konfigurieren gehört zum Alltag. Managed Kubernetes (EKS, AKS, GKE) nimmt den Betrieb der Control Plane ab. Mein Tipp: Managed nutzen, nicht selbst betreiben. Die Zeitersparnis ist den Aufpreis wert. Nicht jeder muss Cluster administrieren, aber jeder Backend-Entwickler sollte verstehen, wie die eigene Anwendung in einem Container läuft, wie Health Checks funktionieren und warum ein sauberes Dockerfile den Unterschied zwischen einem stabilen und einem fragilen Deployment ausmacht.
Was kostet das? Ein kleiner Kubernetes-Cluster auf AWS (EKS) schlägt mit mindestens 150 bis 200 Euro pro Monat zu Buche: 72 Euro für die Control Plane plus Rechenkapazität. Azure bietet mit AKS einen kostenlosen Free Tier für die Control Plane, womit ein Minimal-Cluster ab 60 bis 80 Euro monatlich möglich ist. Für Einzelentwickler gibt es günstigere Wege: Railway startet bei fünf Euro pro Monat, Vercel bietet einen kostenlosen Hobby-Plan. AWS- und Azure-Zertifizierungen kosten zwischen 100 und 300 Dollar pro Prüfung, wobei nach bestandener Prüfung ein 50-Prozent-Gutschein für die nächste winkt.
Macht Serverless Backend-Entwickler überflüssig?
AWS Lambda, Azure Functions und Google Cloud Functions ermöglichen Code ohne Serververwaltung. Klingt verlockend. Keine Infrastruktur-Wartung, automatische Skalierung, Bezahlung nur bei Nutzung. Die Realität sieht anders aus: Serverless verschiebt Komplexität, statt sie zu beseitigen. Cold Starts, Vendor Lock-in, schwieriges Debugging, Kostenüberraschungen bei hoher Last.
Serverless eignet sich für Event-getriebene Workloads: Bildverarbeitung, Webhooks, geplante Jobs. Für Anwendungen mit konstanter Last und komplexer Geschäftslogik bleibt ein herkömmlicher Server oder Container die bessere Wahl. Backend-Entwickler werden durch Serverless nicht überflüssig. Sie brauchen nur eine zusätzliche Perspektive für die Architekturwahl.
Tooling: Was noch dazugehört
Sprache, Framework, Datenbank, Cloud. Reicht das? Nicht ganz. Drei weitere Kompetenzbereiche gehören zum Backend-Alltag, auch wenn Stellenanzeigen sie oft nur beiläufig erwähnen.
CI/CD ist Grundvoraussetzung, nicht Bonus. GitHub Actions und GitLab CI dominieren den Markt. Code, der automatisch getestet, gebaut und deployed wird, produziert weniger Fehler. Die Lernkurve für eine einfache Build-Pipeline liegt bei ein bis zwei Tagen. Keine Ausrede also.
Observability klingt abstrakt, ist aber konkret: Wenn ein Service um drei Uhr nachts ausfällt, muss jemand herausfinden warum. Prometheus für Metriken und Grafana für Dashboards sind der De-facto-Standard, beide übrigens in Go geschrieben. Logging mit dem ELK-Stack (Elasticsearch, Logstash, Kibana) oder leichtgewichtiger mit Loki ergänzt das Bild. Wer schon einmal einen Bug in der Produktion gesucht hat, ohne strukturierte Logs zur Verfügung zu haben, weiß warum diese Tools kein Luxus sind, sondern Grundlage für jede ernsthafte Backend-Arbeit.
Containerisierung mit Docker gehört zum Handwerk. Jeder Backend-Entwickler sollte ein Dockerfile schreiben und lokale Entwicklungsumgebungen mit Docker Compose aufsetzen können. Kein Spezialistenwissen. Grundkompetenz.
REST, GraphQL oder gRPC: Wann welche API?
Drei Paradigmen, eine Frage: Wie sollen Services miteinander reden? Die Antwort hängt weniger von der Technologie ab als vom Einsatzzweck.
REST bleibt der Standard für Web-APIs. Einfach zu verstehen, gut dokumentierbar mit OpenAPI/Swagger, von jedem HTTP-Client nutzbar. Für die überwiegende Mehrheit der Projekte ist REST die richtige Wahl. Nicht weil es das beste Paradigma wäre, sondern weil es das am breitesten verstandene ist.
GraphQL löst ein echtes Problem: Over- und Under-Fetching bei komplexen, verschachtelten Datenstrukturen. Mobile Apps, die mit begrenzter Bandbreite arbeiten, profitieren davon, genau die Felder abzufragen, die sie brauchen. Zalando nutzt GraphQL für seine Storefront-APIs. Kehrseite: höhere Komplexität auf der Serverseite, schwierigeres Caching, potenzielle Performance-Probleme durch zu tiefe Abfragen.
gRPC nutzt Protocol Buffers für schnelle, typsichere Kommunikation zwischen Services. Ideal für Microservice-zu-Microservice-Kommunikation, wo Geschwindigkeit zählt und kein Browser beteiligt ist. Browser können gRPC nicht nativ sprechen.
Meine Empfehlung: REST lernen und beherrschen. GraphQL verstehen, aber nur einsetzen, wenn das Problem es rechtfertigt. gRPC für interne Service-Kommunikation in Betracht ziehen, wenn Performance kritisch ist.
Microservices oder Monolith: Was funktioniert wirklich?
Amazon konsolidierte seinen Prime-Video-Monitoring-Dienst von Microservices zurück auf einen Monolithen und senkte die Kosten um 90 Prozent [6]. Das war 2023. Seitdem hat sich die Debatte spürbar verschoben. Service-Mesh-Adoption in der CNCF-Umfrage sank von 50 Prozent (2023) auf 42 Prozent (2024). Nicht weil Microservices grundsätzlich falsch wären, sondern weil viele Teams die organisatorische Komplexität unterschätzt haben.
Der Modular Monolith entwickelt sich zum überzeugendsten Mittelweg. Klare Modul-Grenzen innerhalb einer Deployment-Einheit, ohne den Overhead verteilter Systeme. Shopify beweist, dass dieser Ansatz skaliert: Am Black Friday 2024 verarbeitete ihre modulare Rails-Anwendung 173 Milliarden Requests an einem einzigen Tag, Spitze bei 284 Millionen Requests pro Minute [10]. Rund 4.000 Entwickler arbeiten an diesem einen Monolithen. Packwerk erzwingt die Modulgrenzen, Database Sharding nach Shop-ID verteilt die Last. Ein Team, das über Microservices nachdenkt, sollte zuerst fragen: Haben wir Shopifys Problem? Meistens lautet die Antwort: Nein.
Event-Driven Architecture verdient Erwähnung als dritte Option. Statt synchroner Aufrufe kommunizieren Services über Events und Message Queues wie Kafka oder RabbitMQ. Für asynchrone Prozesse wie Bestellverarbeitung, Benachrichtigungen oder Daten-Pipelines ist dieses Muster oft die eleganteste Lösung. Zalando etwa verarbeitet Millionen von Events pro Tag über Apache Kafka, vom Wareneingang über Preisänderungen bis zur Auslieferungsbenachrichtigung.
Ich halte den Trend zur Rückbesinnung auf einfachere Architekturen für überfällig. Microservices lösen organisatorische Probleme: unabhängige Teams, unterschiedliche Release-Zyklen. Keine technischen. Ein Team mit fünf Entwicklern braucht keine 14 Services. Punkt. Erst bei klarer organisatorischer Notwendigkeit lohnt sich die Verteilung.
Fazit: Weniger ist mehr
Die Backend-Technologielandschaft bietet echte Wahlfreiheit. Stärke und Falle zugleich, weil die Versuchung groß ist, jede neue Sprache und jedes neue Tool zu lernen. Arbeitgeber suchen aber Tiefe, nicht Breite. Eine Sprache beherrschen, eine Datenbank wirklich verstehen, ein Cloud-Umfeld kennen. Das bringt weiter als oberflächliche Kenntnisse in zehn Technologien.
Vier Erkenntnisse aus der Analyse: Erstens hat PostgreSQL die Datenbankwelt konsolidiert, für Einsteiger gibt es keinen besseren Startpunkt. Zweitens sind Cloud- und Kubernetes-Kenntnisse Teil des Backend-Profils, nicht optional. Drittens kehren viele Teams vom Microservice-Hype zum Modular Monolith zurück. Viertens: Tooling wie CI/CD, Docker und Observability gehört genauso zum Job wie das Programmieren selbst.
Wer heute als Backend-Entwickler anfängt, wählt eine Sprache aus den Top Drei (Python, Java oder TypeScript), lernt PostgreSQL als Datenbank und findet sich in einem Cloud-Anbieter zurecht. Alles andere ergibt sich aus den konkreten Anforderungen der ersten Stelle. Im DACH-Raum öffnet Java die meisten Türen im Enterprise-Bereich, Python punktet bei Startups und datengetriebenen Unternehmen, TypeScript bei Agenturen und Produktfirmen mit Fullstack-Ansatz. Überraschend, aber wahr: Welche der drei Sprachen man wählt, ist weniger entscheidend als die Fähigkeit, eine davon gründlich zu beherrschen und das umgebende Tooling souverän einzusetzen, von der Datenbank über CI/CD bis zur Cloud-Deployment-Pipeline.
Im nächsten Teil geht es um den Einstieg in den Beruf: Studium, Ausbildung, Bootcamp oder autodidaktisch. Welcher Weg führt am zuverlässigsten in die Backend-Entwicklung, und was sollte man dabei beachten?
Quellen
[1] TIOBE Index, Februar 2026 (https://www.tiobe.com/tiobe-index/)
[2] Stack Overflow Developer Survey 2025: Most Admired Languages (https://survey.stackoverflow.co/2025/)
[3] Stack Overflow Developer Survey 2025: Databases (https://survey.stackoverflow.co/2025/)
[4] Synergy Research Group: Cloud Market Share Q4 2025 (https://www.srgresearch.com/)
[5] CNCF Annual Survey 2024: Kubernetes Adoption (https://www.cncf.io/reports/cncf-annual-survey-2024/)
[6] Amazon Prime Video: Scaling up the Prime Video monitoring service (https://www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types); CNCF Annual Survey 2024: Service Mesh Adoption (https://www.cncf.io/reports/cncf-annual-survey-2024/)
[7] OpenAI: Scaling PostgreSQL to 800 Million Users (https://openai.com/index/scaling-postgresql/)
[8] DB-Engines Ranking, Februar 2026 (https://db-engines.com/de/ranking)
[9] Linux Foundation: Valkey 9.0 (https://www.linuxfoundation.org/press/valkey-9.0-delivers-performance-and-resiliency-for-real-time-workloads)
[10] Shopify: BFCM 2024 Data (https://www.shopify.com/news/bfcm-data-2024); Shopify Engineering: The Monolith (https://shopify.engineering/shopify-monolith)
[11] PostgreSQL 18 Released (https://www.postgresql.org/about/news/postgresql-18-released-3142/)
[12] MySQL Product Support EOL Announcements (https://www.mysql.com/support/eol-notice.html)