"Ich würde möglicherweise nicht mehr empfehlen, Informatik zu studieren", schlägt ein Turing-Preisträger einen Großteil der Branche an und behauptet: Am Ende handelt es sich bei AI Agenten nur um Datenbankprobleme.

„Wenn ich es heute noch einmal von vorne beginnen würde, bin ich nicht sicher, ob ich noch immer 18 - jährigen Leuten raten würde, Informatik zu studieren.“

Derjenige, der diese Worte sagte, ist der Turing - Preis - Gewinner im Bereich Datenbanken, Mike Stonebraker, der in Deutsch häufig als „Mike Stonebraker“ übersetzt wird. Er ist der Schlüsselschöpfer hinter Ingres und Postgres und einer der wichtigsten Personen im Datenbankbereich. Nach seiner Meinung wird Informatik in Zukunft wahrscheinlich kein wachsender Sektor mehr sein.

In diesem Interview hat Stonebraker fast die gesamte Datenbankbranche kritisiert.

Er hat Oracle kritisiert und direkt gesagt, dass Larry Ellison damals „gelogen“ hat: Er hat Kunden Funktionen verkauft, die noch nicht implementiert waren, die Zukunft als Gegenwart dargestellt und dann die ersten Kunden gebeten, für ihn zu debuggen.

Er hat Google kritisiert und gesagt, dass es „dumm“ war, als Google damals MapReduce und die endgültige Konsistenz propagierte. Viele Leute haben einfach blind darauf vertraut, dass Google weiß, was es tut, nur weil „Google sehr clever“ ist. Aber nach Stonebrakers Meinung ist Hadoop unglaublich ineffizient, und die endgültige Konsistenz eignet sich nur für sehr wenige Szenarien. Als Spanner herauskam, hat Google sich praktisch selbst zugestanden, dass man die alten Datenbankprobleme wie Transaktionen und Konsistenz nicht umgehen kann.

Er hat auch AWS kritisiert: Amazon unterhält etwa 15 verschiedene Datenbanksysteme gleichzeitig, während er meint, dass man wahrscheinlich nur 3 braucht. Graphdatenbanken und Datenbanksysteme mit wiederholten Funktionen haben in seiner Ansicht oft nicht genug Leistung und Marktgründe, um weiter zu existieren.

Interessanter ist aber seine Meinung zu der aktuellen Welle von KI.

Nach seiner Meinung ist die sogenannte agentische KI im Wesentlichen „großes Modell + eine Systemumhüllung“, und die meisten befinden sich noch im „nur - lesenden“ Stadium. Sobald man in die echte Welt des „Lesens und Schreibens“ eintritt - zum Beispiel bei Geldüberweisungen oder Lagerbestandsupdates - treten die alten Datenbankprobleme wie Transaktionen, Konsistenz und Atomizität wieder auf. Dies ist kein KI - Problem, sondern ein Problem verteilter Datenbanken.

Ein weiterer Punkt ist seine Einschätzung darüber, ob große Modelle SQL schreiben können.

In öffentlichen Benchmarks kann das Modell bereits eine Genauigkeit von über 80 % erreichen und scheint nur noch einen Schritt von der Produktion entfernt zu sein. Aber in unseren Tests mit realen Data Warehouses war das Ergebnis - 0 %. Selbst wenn man RAG hinzufügt oder sogar die Join - Bedingungen direkt an das Modell übergibt, kann man höchstens 35 % erreichen. Ein erfahrener menschlicher Ingenieur kann dagegen über 90 % erreichen. Deshalb hat er direkt die Schlussfolgerung gezogen, dass diese Technologie zumindest in absehbarer Zukunft nicht für die Produktion geeignet ist.

Hier ist das vollständige Interview.

1  Postgres: Der beste Ausgangspunkt, aber kein Ziel 

Moderator: Ich möchte zunächst über den Ursprung von Postgres sprechen. Aber bevor ich das tue, möchte ich lieber von Anfang an fragen: Wie bist du in den Datenbankbereich gekommen?

Mike Stonebraker: Nach meinem Abschluss war ich glücklich, von Berkeley eingestellt zu werden. Damals wusste ich genau, dass es keine Zukunft hatte, wenn ich weiter in der Richtung arbeitete, die ich während meines Promotionsstudiums verfolgt hatte, sowohl damals als auch heute. Der beste Weg war, einen Mentor zu finden, der wirklich Ahnung hat und dich einführt.

Also hat Gene Wong mich bei sich herumgenommen und gesagt, wir machen mal etwas zusammen. Das war 1971, ein Jahr nach der Veröffentlichung des bahnbrechenden Artikels von Edgar F. Codd in der CACM (Communications of the ACM).

Gene sagte, wir sollten uns mal mit Datenbanken befassen. Damals gab es hauptsächlich zwei Lager: Einerseits der Codasyl - Vorschlag, den du vielleicht nicht kennst. Es ist eine untere Ebene, eine „spaghetti - artige“ Netzstruktur, bei der man über Zeiger die Abfragen ausführt. Andererseits war es das IBM - Konzept, nämlich IMS, eine hierarchische Datenstruktur, im Wesentlichen ein Baum.

Tatsächlich war IBM damals auch sich bewusst, dass die Baumstruktur nicht universell war und viele Probleme nicht lösen konnte. Also haben sie einige Erweiterungen hinzugefügt und es in eine eingeschränkte Netzstruktur umgewandelt. Aber das war offensichtlich ein sehr schlechtes Patches.

Der Codasyl - Ansatz hatte auch viele Probleme: Er ist sehr tiefgreifend, schwer zu debuggen, und sobald sich das Schema (damals noch nicht so genannt) ändert, muss man im Grunde alles von vorne beginnen, weil es vollständig an die physische Ebene gebunden ist.

Im Vergleich dazu war Codds relationales Modell sehr vernünftig. Also sagte Gene, dass wir es implementieren sollten, das sei das nächste, was zu tun sei. Also begannen wir 1972 mit Ingres, als ich noch ein Assistentprofessor an Berkeley war. Wie du weißt, haben Assistentprofessoren etwa fünf Jahre Zeit, um sich zu beweisen, entweder bekommen sie eine Dauerstelle oder werden entlassen. Ingres war mein Schlüsselprojekt für die Dauerstelle, und ich bekam 1976 die Dauerstelle.

So hat es angefangen. Später gab es noch einige Gelegenheiten. Viele Leute entwickelten damals Prototypen, im Wesentlichen Code auf Studentenarbeitsebene - es lief für sich, aber andere konnten ihn nicht nutzen. Wir haben zunächst die ersten 90 % abgeschlossen und es zum Laufen gebracht; dann haben wir aus irgendeinem Grund noch zusätzliche „90 %“ investiert, um es wirklich zu einem nutzbaren System zu machen.

Die Berkeley - Version von Ingres war wirklich nutzbar. In den folgenden Jahren begannen etwa 100 Universitäten, es zu verwenden, weil Unix populär wurde. Es war ein kostenloser Datenbanksystem, der auf Unix lief und in der akademischen Welt sehr beliebt war. Also kamen viele Leute nach Berkeley und sagten, dass das Ding cool sei und wollten wissen, was die größten Anwendungsfälle seien. Aber wir konnten nur sagen, dass sie eigentlich nicht so groß seien.

Dieses Problem wurde in einem Projekt an der Arizona State University völlig offenbar. Sie überlegten, Ingres zur Verwaltung der Daten von 40.000 Studenten zu verwenden. Sie konnten sich mit dem nicht - offiziellen Betriebssystem von Bell Labs abfinden und auch mit unserem „nicht - offiziellen“ Datenbanksystem, aber das Projekt scheiterte schließlich, weil es auf Unix kein COBOL gab und sie ein COBOL - Unternehmen waren.

Das Fehlen des unterstützten Betriebssystems, des unterstützten Datenbanksystems und von COBOL - das hat uns völlig irrelevant gemacht.

Der einzige Ausweg war, ein Unternehmen zu gründen. Also nahmen wir 1980 das damalige Risikokapital an, gründeten das Ingres - Unternehmen, migrierten das System auf ein „echtes Betriebssystem“ wie VMS und boten kommerziellen Support an. Das war der Beginn der Kommerzialisierung.

Moderator: Ich habe gelesen, dass Ingres damals mit der Oracle Corporation konkurrierte. Technisch war euer System offensichtlich besser, aber Oracle hat dennoch gewonnen. Wie haben sie das geschafft?

Mike Stonebraker: Larry Ellison ist ein sehr guter Verkäufer. Er hat die „Gegenwart“ und die „Zukunft“ so vermischt, dass es im Wesentlichen eine Lüge gegenüber den Kunden war.

Er hat Funktionen verkauft, die noch nicht nutzbar waren, und dann die ersten Kunden gebeten, für ihn zu debuggen. Ich finde, dass dies ein sehr unfaires Geschäftspraktikum ist, und es ist nicht akzeptabel, Kunden zu belügen.

Nehmen wir zum Beispiel die Funktion „referential integrity“ (Referenzintegrität). Wenn du einen Mitarbeiter entlässt und er der letzte in einer Abteilung ist, sollst du diese Abteilung löschen oder eine „leere Abteilung“ behalten? Ähnliche Logik.

Ingres hat diese Funktion implementiert. Oracle hingegen hat damals so vorgegangen: In der Anleitung wurden zwei Seiten über die Referenzintegrität geschrieben (alle stimmen überein, was die Definition ist), aber am Ende der Seite stand ein Hinweis - „noch nicht implementiert“.

Moderator: Ich habe Leute von Sun Microsystems interviewt, und ihre Meinung über Ellison war ähnlich. Es gibt auch die Meinung, dass nach der Übernahme von MySQL durch Oracle viele zu Postgres gewechselt sind, was Postgres zum führenden Open - Source - Datenbanksystem gemacht hat. Was war also die größte Veränderung von Ingres zu Postgres?

Mike Stonebraker: Die Kernveränderung kam eigentlich aus einer anfänglichen Anforderung. Damals wollten wir ein GIS (Geographisches Informationssystem) unterstützen und mussten mit Datentypen wie Punkten, Linien und Polygonen umgehen. Aber Ingres unterstützte nur Standarddatentypen wie Ganzzahlen, Fließkommazahlen und Zeichenketten und konnte GIS nicht effizient unterstützen, also war es in dieser Richtung völlig gescheitert.

Dieser Gedanke hat mich seitdem nicht losgelassen.

Ein weiteres Beispiel: Um 1985 führte die relationale Datenbank ein Datum - und Zeitstandard ein, und Ingres hat das gregorianische Datum entsprechend implementiert. Dann hat ein Kunde angerufen und gesagt, dass wir es falsch implementiert hätten.

Ich habe gesagt, das sei unmöglich, wir hätten es genau nach dem gregorianischen Kalender implementiert und die Datumsberechnungen wären auch korrekt. Er hat gesagt, dass das nicht das sei, was er brauche. Er war in der Bond - Geschäft tätig, und in seiner Welt war der Zins pro Monat fest, egal ob der Monat 28 oder 31 Tage hatte. Das heißt, seine „Datumssubtraktions“ - Regeln waren anders als in der realen Welt. Zum Beispiel würde er von 15. März minus 15. Februar als 30 Tage ansehen. Aber in Ingres waren diese Logiken fest codiert. Er musste die Daten aus der Datenbank holen, in der Anwendungs - Ebene berechnen und dann wieder zurückschreiben, was die Effizienz um das Zwei - bis Dreifache reduzierte.

Er hat mich gefragt, warum man die Subtraktion nicht anpassen könne. Das war das Problem. Dies ist ein Szenario, in dem man „Bond - Zeit“ braucht, genauso wie man Punkte, Linien und Polygone braucht. Also wurde Postgres als ein erweiterbarer Datentypensystem entworfen. Man kann beliebige Datentypen definieren, und die Laufzeitleistung ist sehr hoch. Das ist die Kernidee von Postgres.

Naturgemäß reichen für die meisten kommerziellen Szenarien die Standarddatentypen aus, aber die Datenbanken erweitern sich zunehmend in andere Bereiche wie abstrakte Datentypen und gespeicherte Prozeduren, die alle Erweiterungsfähigkeiten erfordern.

Außerdem unterstützt Postgres die Vererbung (die damalige KI - Forscher brauchten es) und auch die „Zeitreise“ (Abfrage von historischen Daten), aber die Implementierung war sehr schlecht und wurde später entfernt. Insgesamt enthält es jedoch eine Vielzahl sehr interessanter Funktionen.

Moderator: Du hast erwähnt, dass du gut darin bist, gute Ingenieure zu rekrutieren. Wie erkennst du diese „sehr talentierten Leute“?

Mike Stonebraker: Normalerweise erkennt man es auf den ersten Blick. Ich habe ein Gefühl für die „Schwierigkeit“. Wenn ein Student dreimal so viel Arbeit leistet, wie ich für angemessen halte, dann ist er sehr talentiert.

Moderator: Du hast auch einmal etwas Interessantes gesagt: „Ich kann es nicht ausstehen, mit nicht - so - intelligenten Leuten zu sprechen. Es ist schwierig, mit ihnen zu kommunizieren.“ Wie entscheidest du, ob eine Person nicht intelligent genug ist?

Mike Stonebraker: Das ist einfach. Man spricht einfach ein wenig mit ihr. Man fragt sie nach technischen Details, wie was in ihrer Masterarbeit gemacht wurde, wie es konkret implementiert wurde, wie die Fehlerbehandlung funktioniert, wie viele Prozesse verwendet wurden und warum keine Threads - wenn man diese tiefgreifenden Fragen stellt, wird man schnell feststellen können.

Moderator: Du hast früher die These „One size fits none“ aufgestellt, das heißt, ein universeller Datenbanksystem ist keine optimale Lösung und eignet sich eigentlich niemandem.

Mike Stonebraker: Ja, ein universeller Datenbanksystem ist keine optimale Lösung. Das sogenannte „one size fits all“ passt eigentlich niemandem. Was man wirklich braucht, ist eine maßgeschneiderte Datenbanklösung für die spezifischen Anforderungen.

Moderator: Welche Datenbankprodukte gehören heute noch zu dieser Kategorie des „universellen Ansatzes“?

Mike Stonebraker: Als ich 2004 diesen Artikel schrieb, hatten wir gerade ein akademisches Projekt, das später zu StreamBase wurde. Ein Stream - Verarbeitungs - Engine und ein relationaler Datenbanksystem sehen überhaupt nicht ähnlich aus. Gleichzeitig hatten wir auch die grobe Idee für die Spalten - Speicherung in einem Data Warehouse, die später von Vertica populär gemacht wurde, und die Spalten - Speicherung und die Zeilen - Speicherung scheinen auch überhaupt nicht von der gleichen Art zu sein.

Also gab es damals bereits drei sehr unterschiedliche Implementierungen, die fast keine Ähnlichkeiten miteinander hatten, aber in ihren jeweiligen Szenarien eine um Größenordnung höhere Leistung als die traditionellen Lösungen hatten. Das sagt schon viel. Wenn der Datenbanksystem nicht für dein Szenario entwickelt wurde, verlierst du direkt eine um Größenordnung höhere Leistung.

Ich denke, dass es heute immer noch so ist. Zum Beispiel ist ClickHouse eine Spalten - Speicherung. Pinecone ist bei der Verarbeitung von Text - basierten Vektoren auch schneller als die Lösung, die benutzerdefinierte Datentypen verwendet. Also stimmt dies auch heute noch. Ich denke auch, dass es keine Schwierigkeiten gibt, eine einheitliche Parser - Schicht über mehrere unterschiedliche Implementierungen zu legen. Aber Postgres hat dies bis jetzt nicht getan. Es hat keine wirkliche Spalten - Speicherung implementiert und ist daher in großen Data - Warehouse - Szenarien nicht konkurrenzfähig. Es hat auch keine Mehr - Knoten - Unterstützung, was für ein großes Data Warehouse die grundlegende Fähigkeit ist. Also denke ich, dass dies heute genauso wie damals stimmt.

Aber eine andere Tatsache, die auch weiterhin stimmt, ist, dass wenn du einfach nur etwas in Gang bringen möchtest und ein Datenbankproblem hast, die Antwort normalerweise immer noch Postgres ist. Es hat eine große Entwickler - Community, es gibt verschiedene Datentyp - Implementierungen, es ist kostenlos und es ist leicht, Leute zu finden, die mit Postgres vertraut sind, und man kann schnell loslegen.

Also denke ich, dass es als Option für die minimalen universellen Anforderungen sehr gut ist. Solange du nicht Millionen von Transaktionen pro Sekunde verarbeiten musst und auch kein PB - großes Data Warehouse unterstützen musst, reicht es vollkommen aus. Das heißt, in niedrigen Szenarien ist die „universelle Lösung“ Postgres, das ist absolut kein Problem; aber in hohen Szenarien stimmt diese Aussage nicht mehr.

2  Sobald Indizes auftauchen, ist es schwierig, GPU zu nutzen 

Moderator: Können GPU neue Chancen für die Datenbankoptimierung bieten?

Mike Stonebraker: Vielleicht. Aber ich denke, dass die größte Herausforderung darin besteht, dass GPU im Wesentlichen SIMD (single instruction, multiple data) ist, also eine Anweisung für mehrere Daten. Und das steht im Widerspruch zu Indizes.

Sobald Indizes die richtige Lösung sind, ist GPU wahrscheinlich keine gute Lösung.

Außerdem muss man das gesamte System so aufbauen, dass die Bandbreite von der Speicherung bis zur Berechnung kein Engpass wird. Wenn die GPU nur als Zusatz an der CPU hängt, wird oft die Busleitung