OLTP (Online Transaction Processing)

OLTP (Online Transaction Processing) bezeichnet den Betrieb von Datenbanken, die viele kleine, schnelle Schreib- und Lesevorgänge bedienen, etwa das Anlegen einer Bestellung oder das Buchen einer Zahlung. Die Daten liegen dabei zeilenweise gespeichert (ein Datensatz mit allen Feldern zusammen), und jede Änderung wird garantiert vollständig oder gar nicht wirksam (die sogenannten ACID-Garantien: Atomicity, Consistency, Isolation, Durability). OLTP-Systeme tragen operative Anwendungen wie Bestell-, Buchhaltungs- oder Bestandsverwaltung und stehen der analytischen Auswertung großer Datenmengen (OLAP) gegenüber.

Was ist OLTP?

Der Begriff geht auf die Abgrenzung zurück, die E. F. Codd 1985 zusammen mit dem Gegenpol OLAP (Online Analytical Processing) einführte; die Sache selbst existiert seit den 1970er Jahren mit Systemen wie IBM IMS, DB2 und den frühen Oracle- und Sybase-Datenbanken. OLTP beschreibt weniger ein Produkt als ein Lastprofil: eine Datenbank, die viele parallele Nutzer mit vielen kleinen Vorgängen (Transaktionen) bedient, jede davon in Millisekunden bestätigt und dabei konsistent hält, also so, dass zwei gleichzeitig laufende Buchungen sich nicht gegenseitig überschreiben oder halbfertige Zustände hinterlassen.

Technisch sind OLTP-Systeme zeilenorientiert aufgebaut. Ein Datensatz liegt mit allen Spalten physisch zusammen, sodass ein Punktzugriff auf einen Kunden oder eine Bestellung in einer einzigen I/O-Operation gelesen oder geschrieben werden kann. B-Tree- oder LSM-Indizes beschleunigen Punkt-Lookups über Primär- und Fremdschlüssel. Der Puffer-Manager hält häufig genutzte Seiten im Arbeitsspeicher, ein Write-Ahead-Log sichert die Dauerhaftigkeit. [ACID-Transaktionen](/insights/glossar/acid-transactions/) sind das Betriebsversprechen dieser Klasse: eine Änderung wird entweder vollständig oder gar nicht wirksam, auch bei Ausfällen und gleichzeitigen Zugriffen anderer Sessions.

Verbreitete Vertreter sind PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database und IBM DB2. In der Cloud werden dieselben Engines als verwaltete Dienste angeboten: Amazon RDS und Aurora, Azure SQL Database und Azure Database for PostgreSQL, Google Cloud SQL und AlloyDB. Databricks bietet mit [Lakebase](/insights/glossar/lakebase/) eine verwaltete Postgres-Engine direkt im Lakehouse-Workspace für App- und Agenten-State.

Abgrenzung gegen OLAP, HTAP und LTAP

Die klassische Trennlinie verläuft zwischen OLTP (transaktional, zeilenorientiert) und OLAP (analytisch, spaltenorientiert). Zwischen beiden Polen sind in den letzten Jahren mehrere Zwischenmodelle entstanden, die die harte Grenze aufweichen.

OLAP verarbeitet aggregierende Abfragen über große Datenmengen und ist auf einen spaltenorientierten Speicher angewiesen, weil pro Query typischerweise nur wenige Spalten aus vielen Zeilen gelesen werden. [HTAP](/insights/glossar/htap/) versucht, beide Workloads in einer einzigen Engine zu bedienen und nimmt dafür den Engine-Physik-Kompromiss zwischen Row- und Column-Format in Kauf. [LTAP](/insights/glossar/ltap/) trennt die Engines wieder, vereint dafür die Speicher-Schicht: eine OLTP-Engine (Lakebase) und eine OLAP-Engine (Lakehouse) arbeiten auf demselben Objektspeicher. [Zero-ETL](/insights/glossar/zero-etl/) belässt Engines und Stores getrennt und automatisiert nur die Pipeline dazwischen.

Beispiel: OLTP in einer Bestellplattform

Eine Bestellplattform hält Bestellungen, Bestände, Kunden und Preise in einer PostgreSQL-Datenbank. Jede Interaktion mit der Anwendung erzeugt kurze Transaktionen: eine Bestellung anlegen, den Bestand eines Artikels dekrementieren, eine Zahlung buchen, den Kundenstatus aktualisieren. Die Datenbank bestätigt jede dieser Operationen in wenigen Millisekunden, hält dabei Konsistenz zwischen Bestand und Bestellzeilen ein und serialisiert konkurrierende Schreibvorgänge über Transaktions-Isolation.

Reporting auf denselben Daten (Umsatz pro Region und Tag, Lagerumschlag pro Artikelgruppe, Konversionsraten über Kampagnen) läuft nicht direkt auf der OLTP-Datenbank. Solche aggregierenden Abfragen würden die operativen Antwortzeiten belasten und passen physisch schlecht zum zeilenorientierten Format. Ein Data Warehouse oder Lakehouse übernimmt diese Last, gespeist über eine ETL-/CDC-Strecke oder eine Zero-ETL-Integration. Die OLTP-Datenbank bleibt für das Frontend zuständig und liefert die konsistente Sicht auf den aktuellen Zustand des Geschäfts.