Mit LTAP (Lake Transactional/Analytical Processing) stellt Databricks eine Architektur vor, die operative Datenbanken und analytische Systeme enger zusammenführen soll. Statt Daten per ETL- oder CDC-Prozessen zwischen beiden Welten zu kopieren, sollen künftig beide auf derselben Datenbasis arbeiten. Databricks sieht darin eine Antwort auf den zunehmenden Einsatz von KI-Agenten, die jederzeit auf aktuelle Unternehmensdaten zugreifen müssen.

In vielen Unternehmen existieren heute zwei getrennte Datenwelten. Operative Anwendungen speichern ihre Daten für den laufenden Geschäftsbetrieb in Transaktionsdatenbanken wie PostgreSQL oder Oracle. Für Berichte, Analysen oder KI-Anwendungen werden diese Daten anschließend in ein Data Warehouse oder Lakehouse kopiert. Dazwischen liegen ETL-Prozesse oder sogenannte Change-Data-Capture-Pipelines (CDC), die Änderungen laufend zwischen beiden Systemen synchronisieren. Diese Architektur gilt seit Jahren als Standard, verursacht jedoch zusätzlichen Betriebsaufwand, Datenkopien und zeitliche Verzögerungen.

Nach Ansicht von Databricks stößt dieses Modell zunehmend an seine Grenzen. KI-Agenten und moderne Anwendungen benötigten aktuelle operative Daten und könnten nicht mit Minuten oder Stunden alten Replikaten arbeiten. Mit LTAP will der Hersteller deshalb transaktionale und analytische Workloads enger zusammenführen.

Zwei Engines statt einer

Neu ist die Idee allerdings nicht. Bereits vor rund 15 Jahren versuchten HTAP-Systeme (Hybrid Transactional/Analytical Processing), Transaktionen und Analysen in einer gemeinsamen Datenbank-Engine auszuführen. Der Nachteil: Dieselbe Engine musste gleichzeitig schnelle Schreibzugriffe und komplexe analytische Abfragen bewältigen, was häufig zulasten der jeweiligen Optimierung ging.

Genau darin sieht Databricks den entscheidenden Unterschied zu früheren HTAP-Ansätzen. Eine einzelne Engine sei für beide Aufgaben zwangsläufig kompromissbehaftet, erläutert Rich Radley, Vice President Field Engineering EMEA bei Databricks. LTAP setzt stattdessen auf zwei spezialisierte Engines: Lakebase übernimmt die transaktionale Verarbeitung auf Basis von PostgreSQL, das Lakehouse die analytischen Abfragen. Beide greifen jedoch auf dieselbe Datenbasis zu.

Grundlage dafür ist Lakebase, ein serverloses PostgreSQL-System, das Daten direkt im Objektspeicher des Lakehouse ablegt. Nach Angaben des Herstellers werden die für Transaktionsdaten typischen zeilenorientierten Daten beim Schreiben automatisch in ein für analytische Abfragen optimiertes spaltenorientiertes Format überführt.

Erst dadurch können beide Engines dieselbe Datenbasis nutzen, obwohl sie unterschiedliche Anforderungen an die Datenorganisation stellen. Radley bezeichnet diese Echtzeit-Transcodierung als eigentlichen technischen Durchbruch der Architektur. Dadurch können zwei spezialisierte Engines parallel auf denselben Daten arbeiten, ohne dass Daten zwischen operativen und analytischen Systemen repliziert werden müssen.

Gemeinsame Datenbasis statt Datenkopien

Lakebase legt die Daten auf derselben Speicherschicht wie das Lakehouse in offenen Tabellenformaten wie Delta oder Iceberg ab. Über den Unity Catalog werden sie gemeinsam verwaltet; dieser übernimmt Berechtigungen, Metadaten und Governance. Dadurch können sowohl die transaktionale Datenbank als auch das Lakehouse auf dieselbe Datenbasis zugreifen, ohne dass zusätzliche Datenkopien entstehen.

Lakebase ergänzt Databricks zudem um cloud- und regionenübergreifende Disaster Recovery, Git-ähnliche Branches und Snapshots sowie autonome Datenbankfunktionen, bei denen Agenten den Zustand überwachen und Optimierungsvorschläge liefern.

Architektur statt Revolution

Mit seinem Ansatz, transaktionale und analytische Workloads enger zusammenzuführen, will sich Databricks sowohl von den HTAP-Systemen (Hybrid Transactional/Analytical Processing) als auch von den neueren Zero-ETL-Konzepten absetzen. Während HTAP beide Workloads in einer gemeinsamen Engine vereinen wollte, argumentiert Databricks, dass Zero ETL vor allem den Integrationsaufwand zwischen bestehenden Systemen reduziere, die zugrunde liegenden Datenkopien jedoch bestehen blieben. LTAP setzt dagegen auf zwei spezialisierte Engines, die auf einer gemeinsamen Datenbasis arbeiten und Datenkopien vollständig vermeiden sollen.

Ob dieser Architekturansatz ETL- und Replikationsprozesse tatsächlich in größerem Umfang ersetzen kann, muss sich allerdings erst im produktiven Einsatz zeigen. LTAP ist bislang nicht allgemein verfügbar, unabhängige Benchmarks oder belastbare Erfahrungen aus Produktivumgebungen liegen ebenfalls nicht vor.

Zusammen mit Lakehouse//RT zeigt LTAP die strategische Richtung von Databricks: Analyse-, Transaktions- und KI-Workloads sollen künftig nicht mehr über zahlreiche Datenkopien und spezialisierte Zwischensysteme verbunden werden, sondern auf einer gemeinsamen Datenbasis zusammenlaufen. Sollte sich dieser Architekturansatz im produktiven Einsatz bewähren, könnte er den Aufbau datenintensiver KI-Anwendungen und Agentensysteme vereinfachen.

(axk)

IBMs Forschungsabteilung hat einen neuartigen Fertigungsprozess entworfen, den die Firma der 0,7-Nanometer-Generation alias 7 Ångström (7A) zuordnet. Die Versprechen sind enorm: Verglichen mit dem selbst entworfenen 2-nm-Prozess von 2021 soll sich die Transistordichte verdoppeln. Die Performance bei gleicher elektrischer Leistungsaufnahme steigt um bis zu 50 Prozent, alternativ sinkt der Energiebedarf bei gleicher Performance um bis zu 70 Prozent.

Damit ist nicht Schluss: Laut Mitteilung soll sich auch der in Prozessoren, Grafikchips und anderen Chiptypen integrierte SRAM-Cache um 40 Prozent verkleinern lassen. Das wäre ein enormer Sprung, nachdem sich die SRAM-Skalierung in den vergangenen Fertigungsgenerationen einer Wand genähert hatte.

Wie üblich haben Nanometer- beziehungsweise Ångström-Namen nichts mit den tatsächlichen Dimensionen zu tun. Ein einzelner Chip hat zahlreiche Metriken, anhand derer sich die Größen messen lassen. Die Mitten zweier Transistoren etwa sollen bei IBMs 7A 42 bis 45 nm voneinander entfernt sein (Contacted Poly Pitch, CPP).

Nanostacks: Gestapelte Transistorpaare

Verglichen mit der 2-nm-Generation entsprächen bis zu 42 nm CPP nur einem kleinen Fortschritt. Der Clou liegt beim Aufbau der Transistorpaare für die entgegengesetzten Stromfluss-Richtungen: In jedem Chip sitzt ein Paar aus PMOS- und NMOS-Transistor, die sich bisher immer nebeneinander befanden. IBM stapelt sie jedoch übereinander, um den Platz in der Breite effektiv zu verdoppeln.

Die Firma nimmt damit den Wechsel auf komplementäre Feldeffekttransistoren (CFETs) vorweg. Die weltweit führenden Chipauftragsfertiger TSMC, Samsung und Intel betrachten CFETs für die frühen 2030er-Jahre als wahrscheinlichste Nachfolger der aktuellen Gate-All-Around-Transistoren (GAA-FETs).

Derzeitige CFET-Konzepte stellen prinzipiell zwei übereinander angeordnete GAA-FETs dar, so auch bei IBM. Die Firma wechselt den Markennamen daher von Nanosheets auf Nanostacks.

Wafer-Bonding

IBM setzt dafür zwei separat belichtete und stark ausgedünnte Silizium-Wafer übereinander (Bonding). Nach jahrelanger Forschung soll sich dieser Ansatz gegenüber monolithischen Wafern als vorteilhaft herausgestellt haben.

Der Hersteller kann so die Atomanordnung einzeln für die NMOS- und PMOS-Richtungen optimieren. Dafür steigt die Fertigungskomplexität, was wiederum die Kosten hochtreibt. IBMs Ansatz könnte daher primär für High-End-Chips wie KI-Beschleuniger interessant sein.

Eine Analyse von More Than Moore liefert Details zu IBMs „Secret Sauce“ beim Wafer-Bonding. Nur äußerlich ähnelt die Vorgehensweise AMDs und TSMCs 3D-V-Cache, bei dem zusätzliche Cache-Dies über den Compute-Dies mit den Rechenkernen liegen, etwa beim Ryzen 9 9950X3D2 Dual Edition.

Unter der Haube ätzt IBM jedoch keine Durchkontaktierungen (Through-Silicon Vias, TSVs) in die Chips, um Verbindungen für den Daten- und Stromfluss herzustellen. Stattdessen sind die Transistorpaare über ein Dielektrikum direkt miteinander verbunden. More Than Moore schätzt, dass IBM je nach Chipspezifikation auf 382 Millionen bis 548 Millionen Transistoren pro Quadratmillimeter Fläche kommt. Zum Vergleich: TSMCs N2-Prozess schafft etwa 236 Millionen.

Ab 2031 serienreif

IBM produziert seit der Übergabe der eigenen Halbleiterwerke an Globalfoundries zwar keine Chips mehr selbst in Serie, ist bei der Forschung aber weiterhin ein wichtiger Spieler. Der junge japanische Chipauftragsfertiger Rapidus lizenziert etwa IBM-Technik. So überrascht es auch nicht, dass Tokyo Electron (TEL) an der 7A-Entwicklung beteiligt war. Ebenfalls dabei: Lam Research und Screen Semiconductor Solutions. Alle drei Partner entwerfen Maschinen und Verfahren zur Wafer-Verarbeitung.

Laut eigenen Angaben könnte sich der Nanostack-Ansatz in fünf Jahren für die Serienfertigung bewähren. Damit läge IBM im industrieweiten Zeitplan. TSMC, Intel und Samsung bringen bis dahin Übergangsschritte zur Marktreife.

(mma)

Eine Funktion erwartet eine Zahl, aber irgendwo im Projekt wird stattdessen eine Zeichenkette übergeben. Der Compiler sagt nichts, die Tests decken den Fall nicht ab, und der Fehler tritt erst auf, wenn ein Kunde in der Produktion genau diesen Codepfad auslöst. Wer mit dynamisch getypten Sprachen arbeitet, kennt diese Klasse von Bugs: Typen werden erst zur Laufzeit geprüft, der Compiler trifft über sie von sich aus keine Annahmen.

Python, Ruby und JavaScript funktionieren nach diesem Prinzip, die funktionale Programmiersprache Elixir ebenfalls. Der Komfort: Code bleibt knapp und lässt sich leicht umbauen. Der Preis: Fehler werden erst sichtbar, wenn das Programm auf den unerwarteten Wert trifft.

Ein Beispiel zeigt, was sich bei Elixir mit dem am 3. Juni 2026 erschienenen Release 1.20 ändert. Die folgende Funktion nimmt eine Map entgegen, Elixirs Schlüssel-Wert-Struktur (geschrieben %{schlüssel: wert}, vergleichbar einem Dictionary in Python oder einem Hash in Ruby), und wandelt das darin enthaltene Feld age in eine Zeichenkette um:

defmodule Report do
  def user_age_to_string(user) do
    Integer.to_string(user.age)
  end
end

# An anderer Stelle im Projekt:
Report.user_age_to_string(%{age: "42"})

Integer.to_string/1 ist dabei Elixirs übliche Schreibweise für eine Funktion: Modul, Funktionsname und nach dem Schrägstrich die Stelligkeit (Arity), also die Zahl der Argumente. Bis einschließlich Version 1.19 schwieg der Compiler zu diesem Code; dass age eine Zeichenkette statt einer Zahl enthält, fiel erst zur Laufzeit auf. Ab 1.20 erscheint eine Warnung beim Übersetzen:

warning: incompatible types given to Report.user_age_to_string/1:

    Report.user_age_to_string(%{age: "42"})

given types:

    %{age: binary()}

but expected one of:

    %{..., age: integer()}

Zwei Notationen darin sind erklärungsbedürftig (Typnamen tragen in Elixir stets leere Klammern). binary() ist Elixirs Typ für Zeichenketten, denn Strings sind in Elixir intern UTF-8-kodierte Binärdaten. Und die Ellipse in %{..., age: integer()} steht für beliebige weitere Schlüssel: Gemeint ist jede Map, die mindestens den Schlüssel age mit einem integer(), einer ganzen Zahl, enthält.

Niemand hat dem Compiler mitgeteilt, welchen Typ user.age haben soll. Er hat es selbst erschlossen: Integer.to_string/1 verlangt eine ganze Zahl, also muss das Feld age eine ganze Zahl enthalten, also muss jeder Aufrufer eine Map mit genau diesem Merkmal übergeben. Die Schlussfolgerung klingt trivial, aber sie steckt in keiner Typannotation, also keinem expliziten Typhinweis im Quelltext, wie ihn typisierte Sprachen verlangen (name: string in TypeScript, String name in Java). In Elixir 1.20 übernimmt der Compiler diese Arbeit von selbst.

Das dahinterstehende Typsystem, das seit Version 1.17 schrittweise in die Sprache einzog, analysiert inzwischen jedes Sprachkonstrukt. Es erkennt nicht nur fehlerhafte Argumente wie im Beispiel oben, sondern verfolgt auch, wie sich das Wissen über einen Wert durch mehrere Fallunterscheidungen hindurch verfeinert, und deckt dabei toten Code und widersprüchliche Zugriffe auf. Was abstrakt klingt, markiert einen Wendepunkt in der Geschichte von Elixir.

Sämtliche Vorteile des neuen Typsystems gibt es automatisch und ohne eigenes Zutun. An der Arbeitsweise muss sich nichts ändern, bestehender Code kompiliert unverändert weiter, niemand muss Typannotationen schreiben oder neue Syntax lernen; die zusätzliche Fehlersuche läuft bei jedem Übersetzen einfach mit.

Elixir kurz erklärt

Elixir ist eine funktionale, dynamisch getypte Sprache, die der Brasilianer José Valim 2012 veröffentlichte. Sie läuft auf der BEAM, der virtuellen Maschine von Erlang, und erbt von dort leichtgewichtige Prozesse im Millionenbereich (von der VM verwaltet, keine Betriebssystemprozesse) sowie eine ausfallsichere Laufzeit durch Supervisoren: überwachende Prozesse, die abgestürzte Teile des Systems automatisch neu starten.

Bekannt ist Elixir vor allem durch das Web-Framework Phoenix, das Embedded-Framework Nerves (Firmware-Images für Geräte vom Raspberry Pi bis zur Industriesteuerung) und Nx, das Elixir in die Welt des maschinellen Lernens bringt. Allen gemein ist ein Programmierstil, den eine kleine Funktion illustriert; sie übersetzt das Ergebnis einer Operation in einen lesbaren Satz:

defmodule Ergebnis do
  def beschreibe({:ok, wert}),        do: "Erfolg: #{wert}"
  def beschreibe({:error, :timeout}), do: "Zeitüberschreitung"
  def beschreibe({:error, grund}),    do: "Fehler: #{grund}"
  def beschreibe(:pending),           do: "läuft noch"
end

Vier Klauseln, vier Fälle. Eine Funktion darf in Elixir aus mehreren Definitionen gleichen Namens bestehen, den Klauseln; welche läuft, entscheidet kein if oder switch, sondern die Form des Arguments. Diesen Musterabgleich nennt man Pattern Matching. Die erste Klausel greift für einen Tupel, eine geordnete Sammlung fester Länge in geschweiften Klammern, dessen erstes Element das Atom :ok ist; den zweiten Wert bindet sie an die Variable wert und fügt ihn per #{...} in den Antwortsatz ein, Elixirs String-Interpolation, vergleichbar mit f-Strings in Python. Atome wie :ok oder :pending sind benannte Konstanten, deren Wert ihr eigener Name ist, vergleichbar mit Symbols in Ruby. Die zweite Klausel fängt den speziellen Fehlerfall :timeout ab, die dritte jeden anderen Fehler, die vierte das schlichte Atom :pending. Das do: ist die einzeilige Kurzform des do ... end-Blocks aus dem ersten Beispiel.

Zwei Bausteine gehören noch zum Rüstzeug. Erstens: Tupel wie {:ok, wert} und {:error, grund} heißen Result-Tupel; fast jede Elixir-Bibliothek meldet Erfolg oder Misserfolg in dieser Form. Zweitens lassen sich Klauseln durch Guards verfeineren, Prüfbedingungen hinter dem Schlüsselwort when: def halbiere(x) when is_integer(x) greift nur für ganze Zahlen. Patterns, Klauseln und Guards ersetzen in Elixir einen großen Teil des klassischen Kontrollflusses. Und genau dieser Stil galt lange als Hindernis für ein klassisches Typsystem.

Vom dynamischen Liebling zum typisierten Werkzeug

Die Idee, Elixir ein Typsystem zu verpassen, ist alt. Bereits der aus der Erlang-Welt stammende Dialyzer, den Kostis Sagonas an der Universität Uppsala mitentwickelt hat, kann Elixir-Code analysieren. Seine Stärke, das sogenannte Success Typing, liegt darin, nur solche Fehler zu melden, die sich aus dem Code unzweifelhaft ergeben. Sein Potenzial entfaltet er allerdings erst, wenn Entwicklerinnen und Entwickler ihre Funktionen mit @spec-Annotationen versehen: von Hand geschriebene Typsignaturen, die zusätzlich zum eigentlichen Code gepflegt werden wollen und mit ihm auseinanderdriften können. Dazu kommen langsame Analysen, sperrige Integration und schwer entzifferbare Meldungen. In die breite Masse der Elixir-Entwickler hat es Dialyzer deshalb nie geschafft.

José Valim kündigte 2022 in seiner Keynote auf der ElixirConf EU an, dass die Sprache ein eigenes Typsystem bekommen werde, finanziert über ein Promotionsstipendium des französischen Forschungszentrums CNRS und des Unternehmens Remote. Die wissenschaftliche Grundlage lieferte der Informatiker Giuseppe Castagna (CNRS, Paris) mit seiner Arbeit zu set-theoretischen Typen, einem Formalismus, der Typen als Mengen begreift. Castagnas Doktorand Guillaume Duboc übernahm den Großteil der Implementierung, unterstützt durch Valim selbst; die Designprinzipien dokumentieren die drei in einem gemeinsamen Paper. Für eine Sprache, in der Pattern Matching ohnehin um die Form von Werten kreist, passte dieser Ansatz besser als klassische Typsysteme nach dem Vorbild von ML oder Haskell.

Die Entwicklung verlief in vier Etappen (Abbildung 1). Elixir 1.17 legte im Juni 2024 den Grundstein: erste Typen, abgeleitet aus den Patterns einer Funktion, erste Warnungen bei offensichtlichen Widersprüchen. Elixir 1.18 brachte im Dezember 2024 das Typchecking von Funktionsaufrufen, dazu eingebaute JSON-Unterstützung und Schnittstellen für die offizielle Language-Server-Initiative. Elixir 1.19 dehnte die Prüfungen im Oktober 2025 auf Protokolle und anonyme Funktionen aus und machte das Übersetzen großer Projekte bis zu viermal schneller. Version 1.20 schließt den Kreis: Der Compiler inferiert jetzt die Typen sämtlicher Sprachkonstrukte.

Den Rollout hat das Kernteam in einem öffentlichen Phasenplan organisiert, der die Inferenz in drei Phasen durch die Release Candidates trug (siehe Kasten). Alle drei stecken im stabilen Release, das Anfang Juni kurz nach dem ursprünglich angepeilten Mai-Termin erschien.