In der Welt der Datenbanken gab es über Jahrzehnte immer wieder große Paradigmenwechsel. Lange Zeit waren relationale Datenbanksysteme, die sowohl für Online-Transaktionsverarbeitung (OLTP) als auch für Online-Analytische Verarbeitung (OLAP) genutzt wurden, der Standard. Diese All-in-One-Lösungen wuchsen in den 1980er Jahren heran, als Datenmengen noch überschaubar waren und Hardware-Ressourcen erheblich teurer als heute. Systeme wie Oracle V2 oder IBM DB2 meisterten hierbei den Spagat zwischen schnellen Transaktionen und anspruchsvollen Berichtsanforderungen. Ein eigenes Schlagwort wie HTAP gab es damals noch nicht – es war schlicht die Datenbank, die alles abdeckte. Doch die Anforderungen wuchsen mit der Zeit und in den 1990er Jahren zeigte sich schnell eine immer größer werdende Kluft zwischen den Bedürfnissen der Echtzeit-Transaktionen und der analytischen Verarbeitung großer Datenmengen.
OLTP verlangte nach schnellen, punktgenauen Datenzugriffen mit minimalen Latenzen, während OLAP zunehmend ganze Datensätze scannte und komplexe Aggregationen berechnete. Die konkurrierenden Zugriffe auf Speicher und Ein-/Ausgabe-Ressourcen führten zu Leistungseinbrüchen und Engpässen. Somit entstand die sogenannte „Große Teilung“ der Datenbanklandschaft, in der spezialisierte Systeme für Transactional und Analytical Workloads eingeführt wurden. Technologisch spiegelte sich diese Trennung auch in der Speicherorganisation wider: OLTP setzte auf zeilenorientierten Speicher, um schnelle Inserts und punktuelle Abfragen zu ermöglichen, während OLAP auf spaltenorientierte Speicherlösungen setzte, um Strategien wie „Full Table Scans“ und große Aggregationen effizienter zu gestalten.
Diese Aufteilung festigte sich während der 2000er Jahre und wurde zum Industriestandard, wie unter anderem von Michael Stonebraker in seinem einflussreichen Papier „One Size Fits All: An Idea Whose Time Has Come and Gone“ beschrieben. Hinzu kam, dass mit dem Aufkommen von Big Data und der Notwendigkeit zur horizontalen Skalierung die beiden Bereiche sich noch weiter entfernten. Auf der OLTP-Seite entstanden oft NoSQL-Datenbanken, die den Verzicht auf klassische SQL Eigenschaften zugunsten von Performance und Flexibilität in Kauf nahmen. Für Analytics dominierten MPP-Architekturen, Data Lakes und MapReduce-Modelle, die massive Mengen an Daten schnell durchlaufen konnten, aber dabei auf Konsistenz und Transaktionssicherheit verzichteten. Erst in den 2010er Jahren kam es dann zu einer überraschenden Konvergenz.
Neue NewSQL-Systeme zeigten, dass Transaktionssysteme SQL-basierte Funktionen auch im verteilten Kontext anbieten können, während auf der Analytic-Seite Cloud Data Warehouses wie Redshift oder Snowflake als relationale MPP-Systeme mit starken Konsistenzgarantien etabliert wurden. Beide Seiten verwendeten dabei ähnliche Architekturprinzipien wie verteilte Ausführung und SQL-Unterstützung, der entscheidende Unterschied lag weiterhin im teilweise unterschiedlichen Speicher-Design der Engines. Die Frage stellte sich: Warum nicht beides in einem System kombinieren? 2014 dann prägte Gartner den Begriff HTAP, der das Ziel hatte, Transaktions- und analytische Workloads nahtlos in einem einzelnen Datenbanksystem zu integrieren. Diese Vision versprach den Unternehmen Analysen auf aktuellen Daten ohne Verzögerungen, was für sensible Anwendungsfälle wie dynamische Preisgestaltung, Betrugserkennung oder individualisierte Angebote essenziell war.
Erste Produkte wie SingleStoreDB kombinierten In-Memory Rowstore mit persistenter Columnstore-Technologie und einer Vektor-basierten Ausführungsmaschine, um sowohl schnelle Schreib- und Leseoperationen als auch große Scan- und Aggregationsabfragen abzudecken. Ebenso versuchte TiDB den Spagat, indem es einen separaten zeilenbasierten Speicher mit einer auf ClickHouse basierenden Spaltenengine koppelte, wenngleich hier ein Double-Write-Ansatz mit zwei Datenkopien nötig war. Trotz dieser vielversprechenden Konzepte konnte HTAP jedoch nie vollständig Fuß fassen. Im Laufe der 2020er Jahre kristallisierte sich heraus, dass Cloud Data Warehouses als eigenständige Systeme zum dominierenden Ansatz für analytische Arbeiten wurden, während die NewSQL-Bewegung für OLTP an Momentum verlor.
Es gibt mehrere Gründe für das faktische Aus von HTAP als Monolith: Der Wechsel von etablierten OLTP-Systemen ist außerordentlich schwierig, wie die andauernde Dominanz von Datenbanken wie Oracle oder SQL Server zeigt. Die meisten Transaktionsworkloads kommen auch heute noch mit leistungsfähiger Einzelhardware aus, die kostengünstig und extrem leistungsstark ist. Zudem favorisieren Cloud-Architekturen Shared-Disk-Modelle gegenüber Shared-Nothing, was die Anforderungen an Localität und Speichergeschwindigkeit verändert. Nicht zuletzt werden OLTP und OLAP oft von unabhängigen Teams betreut, deren Zielsetzungen und Anreize kaum auf eine Konsolidierung der Datenbanken ausgelegt sind. Stattdessen entsteht eine neue Ära der Datenarchitektur, in der modulare, spezialisierte Komponenten mittels leistungsfähiger Pipelines und Protokolle zusammenspielen.
Hierbei werden klassische OLTP-Systeme durch Stream-Prozessoren als Write-Ahead-Log-Quellen ergänzt, datenbezogene Open Table Formate wie Apache Iceberg fungieren als Storage Engines und ausgefeilte Query-Engines wie Apache Spark oder Trino übernehmen die Ausführungslogik. Für Echtzeit-Analysen kommen Systeme wie ClickHouse oder Elastic als sekundäre Index-Layer zum Einsatz. Datenarchitekturen lösen sich somit von monolithischen HTAP-Systemen hin zu einer „best-of-breed“-Zusammensetzung aus mehreren spezialisierten Bausteinen. Die Herausforderungen verschieben sich folglich weg von der Vereinigung der Workloads in einer Datenbank hin zur effizienten Integration und Synchronisation dieser Komponenten. Eine zentrale Fragestellung stellt dabei dar, wie der Write-Ahead-Log von OLTP-Systemen effizient auf die Storage Layer eines Data Lake angewendet werden kann, oder wie Echtzeit-Indizes kostengünstig aufgebaut und aktuell gehalten werden.
Die moderne Datenwelt strebt somit eher eine reale „Lakehouse“-Funktionalität an, bei der Datenströme und Abfragen nahezu verzögerungsfrei über heterogene Systeme laufen. Nach zehn Jahren intensiver Entwicklungen im HTAP-Bereich zeigt sich somit klar: HTAP als Monolith ist bedeutungslos geworden. Die Idee, Transaktions- und Analysesysteme in einem einzigen System vollständig zu vereinen, hat sich praktisch erledigt. Dennoch lebt der Geist von HTAP weiter – nämlich im Anspruch, auf aktuelle Daten schnell und präzise zuzugreifen, und dies in einer zunehmend dezidiert modularen Architektur. Von der Zusammenführung verschiedener Technologien im gleichen System geht der Trend hin zum Zusammenspiel mehrerer spezialisierter Systeme, die sich über moderne Standards und Schnittstellen orchestrieren lassen.
Unternehmen profitieren von dieser Flexibilität, um ihre Dateninfrastrukturen maßgeschneidert auf ihre Anforderungen anzupassen und zugleich Skalierung, Verfügbarkeit und Kostenoptimierung zu maximieren. Damit bleibt die zentrale Botschaft: Anstatt HTAP als Einheitslösung zu verfolgen, sollte der Fokus auf die Komposition leistungsfähiger, integrierter Systeme liegen, die gemeinsam die Anforderungen der heutigen, dynamischen Datenlandschaft erfüllen. Die Zukunft liegt in smarten Architekturen, die getrennte Workloads harmonisch miteinander verbinden - nicht mehr zwangsläufig in der monolithischen Vereinigung von OLTP und OLAP unter einem System. HTAP ist tot – lang lebe die modulare Datenlandschaft!
