SQL ist tot. Es lebe SQL!
Ich arbeite seit 30 Jahren in der Enterprise-IT. Lange genug, um viele Hypes kommen und gehen zu sehen und einen Friedhof voller gescheiterter Versprechen, die Vertriebsleute und Berater als echten, bahnbrechenden technologischen Impact für Unternehmen angekündigt hatten.
Hier sind einige Beispiele für Dinge, die uns als eine Art heiliger Gral verkauft wurden, sich dann aber als Eintagsfliegen erwiesen oder nach ihrem kurzen Ruhm in Nischen endeten.
Es gibt aber auch die Gegenbeispiele. Technologien, die schon vor Jahrzehnten für tot erklärt wurden, haben es bis in das Zeitalter der AI geschafft und sind heute munter am Leben.

Die meisten langfristigen Vorhersagen zur Technologieadoption treffen schlicht nicht ein.
Es gibt viele Faktoren, die dazu beitragen, aber einer sticht heraus. Wir haben eine notorische Tendenz, die Trägheit bei der Einführung von Technologien zu unterschätzen, insbesondere in der Enterprise-IT.
Das hat zum Teil sicher mit der menschlichen Natur zu tun, vor allem aber mit der Erfahrung von Fachleuten in Enterprise-IT-Umgebungen. Ja, IT muss wirkungsvolle Innovation für das Unternehmen liefern, um die Wettbewerbsfähigkeit zu verbessern und Wachstum zu stützen. Aber die Kernfunktion der IT-Führung besteht darin, Risiken zu steuern und Kosten in einer vernünftigen Balance zu optimieren, damit der Betrieb weiterläuft. Dabei geht es sowohl um Menschen als auch um Technologie und weit mehr als nur um Systemverfügbarkeit und Cybersicherheit.
Wie Entscheidungen in der Enterprise-IT getroffen werden
Um ein einfaches Beispiel zu geben: Wenn ich als CTO für ein neues Projekt eine Programmiersprache auswähle, muss ich weit über die Fähigkeiten der Sprache selbst hinausblicken. Andere Faktoren sind für meine Entscheidung sogar noch kritischer. Ich muss in mein Unternehmen hineinschauen und auf den breiteren Markt blicken, um zu verstehen, wie populär die Sprache ist. Wird es leicht sein, Entwickler für diese Sprache einzustellen?
Wenn ich zum Beispiel 2025 zwischen JavaScript und Ruby für ein neues Projekt wählen müsste, würde ich schnell prüfen, dass laut der StackOverflow-Umfrage über 66 % der Entwickler JavaScript kennen, aber nur 6,4 % Ruby (eine mögliche serverseitige Alternative). In so einem Fall würde ich wahrscheinlich selbst dann JavaScript wählen, wenn Ruby die bessere Option wäre. Es geht nicht nur darum, dass Recruiting potenziell einfacher ist; bei einer größeren Entwickler-Community kann man auch mit einem umfassenderen Ökosystem rechnen: Tooling, Support, Verfügbarkeit professioneller Dienstleister und so weiter. Ähnlich priorisieren Unternehmen bei der Wahl eines Recruitment-Marketing-Tools oft Plattformen mit einer robusten Nutzerbasis und starker Ökosystem-Unterstützung,
um langfristige Stabilität und einfachere Integration sicherzustellen.
Dann muss ich die langfristigen Trends betrachten. Wie lange gibt es die Sprache schon? Steigt ihre Nutzung noch, stagniert sie oder nimmt sie bereits ab? Wird sie sich weiterentwickeln, um neue Trends und Innovationen aufzunehmen? Wird es in 5 oder 10 Jahren noch Support geben?
Und genau hier beginnt unsere Geschichte über SQL und seine Historie erst richtig.
Was ist SQL?
SQL ist eine breit genutzte, standardisierte, überwiegend deklarative Programmiersprache mit prozeduralen Elementen, die dazu dient, Datenstrukturen zu definieren sowie Daten zu manipulieren, abzufragen und zu kontrollieren. Sie basiert auf relationaler Algebra und hat frühere Techniken zur Abfrage und Datenmanipulation wie VSAM deutlich verbessert. Eine Anweisung besteht aus Klauseln, Ausdrücken, Prädikaten, Abfragen und rekursiven Teilanweisungen.
Es gab immer herstellerspezifische Erweiterungen und Dialekte, aber der Kern der Sprache entspricht in allen wichtigen Implementierungen dem Standard. Inkompatibilitäten betreffen Datentypen und komplexere Konstrukte.
SQL ist nicht perfekt. Es folgt seinen eleganten mathematischen Grundlagen nicht immer konsequent, ist nicht optimal für hierarchische und graphorientierte Daten und passte nie besonders gut in das objektorientierte Paradigma. Generell integriert es sich weder mit objektorientierten noch mit prozeduralen Sprachen wirklich reibungslos (hier kommt Object-Relational Mapping, also ORM, ins Spiel). Komplexere Statements können sperrig zu schreiben und zu lesen sein, und umfangreiche, komplexe Logik lässt sich nicht effizient vollständig in SQL oder PL/SQL ausdrücken.
Deshalb wurden im Laufe der Zeit viele Alternativen vorgeschlagen, und einige davon wurden recht erfolgreich, etwa Graph-Query-Sprachen und noSQL für Key-Value-Stores und dokumentenorientierte Daten.
Die meisten erfolgreichen Alternativen haben in ihrer Nische jedoch irgendwann ein Plateau erreicht, und tatsächlich beobachten wir in den letzten Jahren sogar eine Rückkehr mancher dieser Ansätze zugunsten von SQL. Gleichzeitig wurden einige dieser Konzepte wie JSON oder Graphen bereits in neuere SQL-Versionen übernommen, wodurch der Bedarf an Alternativen sinkt.
SQL ist alt, aber in diesem Marathon ganz klar der Gewinner.
Die Ursprünge von SQL
Die Ursprünge von SQL reichen bis in die frühen 1970er Jahre zurück. 1970 veröffentlichte Edgar F. Codd A Relational Model of Data for Large Shared Data Banks und führte damit das relationale Modell für Datenbanken ein.
Das war die Geburtsstunde des RDBMS, einer damals völlig neuen Kategorie von IT-Systemen, die heute, 55 Jahre später, immer noch zu den weltweit Top 3 gehört (neben IT-Infrastruktur- und ERP-Systemen). Die Verbreitung von RDBMS wurde durch den Aufstieg von ERP vorangetrieben, und die Verbreitung von SQL ging Hand in Hand damit. Wie Zwillinge kann das eine ohne das andere nicht existieren.
Zwischen 1974 und 1977 wurden zwei große Prototypen relationaler Datenbanksysteme entwickelt. Das waren Ingres, entwickelt an der UC Berkeley (UCB), und System R, entwickelt bei IBM San Jose. Ingres verwendete eine Abfragesprache namens QUEL und führte zur Entstehung von Systemen wie Ingres Corp., MS SQL Server, Sybase, PostgreSQL, Wang’s PACE und Britton-Lee. System R hingegen verwendete die Abfragesprache SEQUEL und trug zur Entwicklung von SQL/DS, DB2, Allbase, Oracle und Non-Stop SQL bei.
In diesem Jahrzehnt wurde auch der Begriff Relational Database Management System, also RDBMS, allgemein anerkannt.
Standardisierung und Verbreitung von SQL
Nach fast 10 Jahren Forschung und Entwicklung zu SQL wurden die 1980er das Jahrzehnt der Kommerzialisierung und Standardisierung von RDBMS. Mehrere kommerzielle Datenbanksysteme kamen in den 1980ern auf den Markt. Dazu gehören Oracle V2 (1979), Sybase SQL Server (1984), IBM DB2 für Mainframes (1983, Nachfolger von System R), IBM Informix (1985), Microsoft SQL Server 1.0 (1987) und SAP DB (1988).
Ein wichtiger Schritt war die Übernahme von SQL als Standardsprache für Datenbanken durch ANSI beziehungsweise ISO in den Jahren 1986 und 1987. Dieser Standard wurde im Laufe der Zeit vielfach überarbeitet, zuletzt 2023.
Zu den Gründen, warum Hersteller die Standardisierung unterstützten, gehörten die Erwartung eines schnelleren Gesamtwachstums mit einem Standard in diesem sich entwickelnden Markt, die Angst, gegenüber Wettbewerbern zu verlieren, wenn sie den Standard nicht unterstützen, die Möglichkeit, den Standard zu beeinflussen, sowie Vorteile für das Ökosystem.
Der frühe Erfolg von SQL kam nicht aus dem Nichts. Es gab eindeutig eine Nachfrage.
Das massive Wachstum begann allerdings erst Anfang der 1990er Jahre. Ausgelöst wurde es durch sinkende Hardwarepreise, den Aufstieg von Client-Server-Architekturen mit UNIX und PC sowie die Verbreitung von ERP. Das war das Jahrzehnt, in dem Open-Source-Datenbanken mit MySQL (1995), PostgreSQL (1996) und MariaDB (1999) aufkamen.
Die Genealogie relationaler Datenbanken ist ziemlich komplex – Details dazu finden Sie hier.

Aktuelle Lage und Ausblick
Kurz gesagt: SQL bleibt. Und nicht nur das. Es ist lebendiger denn je und wächst weiter. Dieser Dinosaurier hat alle seine modernen Konkurrenten an Popularität überlebt und überholt.
Es ist ein perfektes Beispiel dafür, dass die Konzepte des Technology Adoption Lifecycle und des Gartner Hype Cycle langfristig nicht immer gelten. SQL hat nach allen Definitionen eine „späte Phase“ erreicht, wächst aber schneller als je zuvor. Ein Beispiel ist der Gartner Hype Cycle aus dem Jahr 2018, in dem SQL nicht einmal mehr als Kategorie auftauchte (und auch 2025 nicht auftaucht).

In den vergangenen fünf Jahren haben SQL-Datenbanken nicht nur überlebt, sie haben floriert. In der Stack Overflow Developer Survey 2020 gehörten MySQL und PostgreSQL bereits zu den weltweit meistgenutzten Datenbanken. 2025 hat sich ihr Vorsprung nur noch vergrößert. MySQL, PostgreSQL, Microsoft SQL Server und SQLite bilden heute die vier meistgenutzten Datenbanken unter professionellen Entwicklern, weit vor jeder noSQL-Alternative. Trotz jahrelanger Vorhersagen, dass „SQL tot ist“, zeigen die Daten das Gegenteil: SQL bleibt das Rückgrat moderner Software und datengetriebener Systeme.

Warum ist SQL wieder lebendig?
Hier sind meine vier Hypothesen dazu, warum SQL gerade mit voller Kraft zurückkommt. Widersprechen Sie mir gern – ich bin sehr gespannt auf Ihre Einschätzungen.

Fundament
SQL war eine der ersten deklarativen Sprachen (im Gegensatz zu den damals üblichen prozeduralen Sprachen). Eine deklarative Sprache lässt einen beschreiben, was man möchte, statt wie man es umsetzt. Das ist für Nutzer sehr attraktiv, die mit anderen Programmiersprachen weniger vertraut sind. Sie ist sehr leicht zu lernen und anzuwenden (zumindest für grundlegende Anwendungsfälle) und bietet gleichzeitig ein enormes Maß an Flexibilität, wodurch sie sich für ein sehr breites Spektrum an Datenzugriffsmustern eignet, von Ad-hoc-Abfragen bis zum transaktionalen Datenzugriff und zur Datenmanipulation.
Reife
Offensichtlich kann eine Technologie, die über einen so langen Zeitraum entwickelt und gereift ist, als sehr stabil und vollständig gelten. Kein Entscheidungsträger geht ein Technologierisiko ein, wenn er sich für SQL entscheidet.
Verbreitung
Darauf sind wir bereits in der Einleitung eingegangen. Die Verbreitung von SQL ist über lange Zeit gewachsen, mal langsamer, mal schneller, aber inzwischen ist SQL mit großem Abstand der dominierende Akteur als Sprache für den Datenzugriff. Diese Position an sich sichert weiteres Wachstum.
Wenn wir kurz in die betriebswirtschaftliche Theorie des Wettbewerbsvorteils abzweigen, wissen wir, dass Marktführer in Märkten, die auf zweiseitigen Plattformen basieren, einen massiven Wettbewerbsvorteil haben. SQL-basierte relationale Datenbanken bilden in einem weiteren Sinne genau eine solche zweiseitige Plattform:
- Community (oder im Fall von SQL mehrere Communities, da sie sich um einzelne Datenbanksysteme herum organisieren) – dazu gehören SQL-Nutzer, Entwickler und andere Fachleute
- Industrie – dazu gehören Systemanbieter, Professional-Services-Organisationen, Cloud-Service-Provider und andere Akteure.
Hier greifen starke Netzwerkeffekte. Eine größere Community wird das Wachstum des Ökosystems und die Fähigkeiten der Systeme vorantreiben, weil die Industrie von der Marktgröße profitieren will. Gleichzeitig wächst die Community aus sich heraus weiter, weil die Wahl einer Technologie durch Nutzer oder die Organisationen, für die sie arbeiten, ebenfalls von der Größe der Community abhängt, um Risiken zu steuern und Zugang zu Talenten sicherzustellen.
Dieser Effekt ist sehr stark und kann sogar dazu führen, dass Plattformen Anwendungsfälle „einsaugen“, für die sie ursprünglich gar nicht gebaut wurden, etwa Graph- und Vector-Datenbank-Erweiterungen für relationale Datenbanken.
Evolution
Wie in der biologischen Evolution können wir äußere Ereignisse in der technologischen Evolution nicht vorhersagen. Wir können uns erst anpassen, wenn sie eintreten. Nicht die stärkste, schnellste oder größte Spezies hat langfristig die besten Überlebenschancen. Es ist diejenige, die sich am besten an Veränderungen anpassen kann. Das SQL des Jahres 2025 ist nicht mehr das SQL von 1970.
SQL hat auf seinem Weg wichtige Veränderungen aufgenommen, darunter Big Data und verteilte Systeme (Sharding und Partitionierung, verteilte SQL-Datenbanken, spaltenorientierte Speicherung und Analytics), eine reibungslose Integration in moderne Programmier- und AI-Sprachen, Unterstützung für semi-strukturierte und unstrukturierte Daten (JSON, Array-Typen, XML), Anpassung an Echtzeit-Analysen, Unterstützung für Advanced Analytics und ML (zum Beispiel BigQuery ML und PostgreSQL-Erweiterungen), Integration in AI-Pipelines, In-Memory-Verarbeitung, vektorisierte Abfrageausführung und GPU-beschleunigtes ML.
Was kommt als Nächstes für SQL?
SQL hat bewiesen, dass es sich schneller weiterentwickeln kann als die Prognosen über seinen Niedergang. Während AI, Vektorsuche und Echtzeit-Analytik verändern, wie wir Anwendungen bauen, passt sich SQL weiter an, statt zu verschwinden. Die nächste Welle wird SQL nicht ersetzen. Sie wird SQL erweitern. SQL ist die Datenbank der Wahl für AI. Wir werden eine tiefere Integration mit AI-getriebener Datenverarbeitung, vector-native Erweiterungen und cloud-native Skalierung sehen, die Datenbanken dynamischer macht als je zuvor.
Für diejenigen unter uns, die Jahrzehnte an Hypes haben kommen und gehen sehen, fühlt sich die Zukunft von SQL gleichzeitig vertraut und neu an. Es ist immer noch die Sprache der Daten – aber jetzt spricht sie auch die Sprache der Intelligenz. Ich würde mich freuen, Ihr Feedback zu meinen Hypothesen und zur Zukunft von SQL zu hören.
Persönlich glaube ich, dass SQL weiterhin die Zukunft ist, und genau deshalb bauen wir Vela. Vela ist eine moderne Backend-as-a-Service-Plattform auf Basis von Postgres. So können wir zeigen, wie Postgres SQL für heutige Cloud- und AI-Workloads relevant hält.