OLTP und OLAP sind keine konkurrierenden Datenbanksysteme für dieselbe Aufgabe. Das eine erfasst die Transaktionen, auf denen Ihr Unternehmen basiert: Tausende kleiner Lese- und Schreibvorgänge, die in Millisekunden abgeschlossen sein müssen. Das andere beantwortet Fragen zu diesen Transaktionen, indem es Millionen von Zeilen durchsucht, um Berichte oder Dashboards zu erstellen. Die meisten Unternehmen nutzen beide Systeme, verbunden durch eine Pipeline, die Daten vom ersten in das zweite System überträgt. Die spannende Frage ist daher nie, für welches man sich entscheiden soll. Es geht vielmehr darum, ab wann sich das zweite System bezahlt macht und wer für dessen Betrieb verantwortlich ist, sobald es existiert.
Beide Begriffe sind älter als die meisten Systeme, die Ihr Team heute verwendet. Frühe Software speicherte ihre Daten in einer einzigen Datei. Die Probleme wuchsen, relationale Datenbankmanagementsysteme wurden zum Standard und waren über Jahrzehnte hinweg die universelle Lösung für die Datenspeicherung.
Das Internet hat das geändert. Suchmaschinen und soziale Netzwerke modellieren Daten in Bereichen, in denen die Beziehungen zwischen Datensätzen schwer zu definieren oder – wie bei der Indexierung von Dokumenten durch Suchmaschinen – schlichtweg nicht erforderlich sind. Das Vokabular hat diesen Wandel überdauert, weshalb es sich lohnt, OLTP und OLAP präzise zu definieren. Beide Begriffe beschreiben, wie ein Datenspeicher genutzt wird. Keiner von beiden hat jemals ein spezifisches Produkt bezeichnet. Der Begriff OLAP selbst wurde 1993 durch ein Whitepaper von Edgar Codd und seinen Kollegen populär gemacht; er war von Anfang an eine Kategorienbeschreibung und kein Produkt.
Stellen Sie sich ein Geschäft vor. Die Kasse erfasst jeden Verkauf in Echtzeit, Buchung für Buchung. Das muss schnell und präzise gehen, schließlich wartet ein Kunde mit seiner Karte in der Hand. Das Lagerbuch hingegen ist eine andere Aufgabe: Am Ende des Tages nimmt jemand den Kassenbon mit ins Büro und gleicht ihn mit den Aufzeichnungen der letzten Monate ab, um zu analysieren, was sich gut verkauft und was nicht. Dieselben Transaktionen, aber zwei völlig unterschiedliche Arten der Verarbeitung.
Genau das sind OLTP und OLAP. Es sind keine konkurrierenden Ansätze für dasselbe Problem, sondern sich ergänzende Prozesse. OLTP-Systeme liefern die Quelldaten, OLAP-Systeme werten diese aus. Ein Einzelhändler nimmt eine Bestellung in seiner OLTP-Datenbank entgegen und wertet am nächsten Morgen im OLAP-Data-Warehouse aus, wie viele Bestellungen gestern pro Region eingegangen sind.
OLTP steht für Online Transaction Processing. Es beschreibt in der Regel Datenbanken, die die Daten für das Tagesgeschäft eines Systems oder Unternehmens speichern und verwalten. Historisch gesehen war es an relationale Datenbanken gebunden, bei denen der Fokus darauf lag, Vorgänge in einem bestimmten Kontext zu erfassen.
Kurz gesagt: OLTP speichert und verwaltet Daten für den täglichen Betrieb.
Da diese Daten oft geschäftskritisch waren, wurde viel Aufwand betrieben, um deren Atomarität, Konsistenz, Isolation und Dauerhaftigkeit (ACID)zu gewährleisten. Diese vier Eigenschaften wurden 1983 von Theo Härder und Andreas Reuter in ihrem Beitrag Principles of Transaction-Oriented Database Recoverydefiniert und bilden bis heute den Standard. Daten, die nach diesen vier Prinzipien verarbeitet werden, nennt man ACID-konform – genau hier liegen die Stärken relationaler Datenbankmanagementsysteme.
Ein ACID-konformer Speicher allein reicht jedoch nicht aus. Auch die Art und Weise, wie Sie die Daten verarbeiten, ist entscheidend. Wie halten Sie Daten konsistent, wenn Sie Redundanz zulassen? Nehmen wir die Adresse eines Kunden: Wenn der Kunde umzieht, muss die Adresse überall geändert werden. Wenn sie an fünf Stellen gespeichert ist, wird es sehr schwierig, die Konsistenz zu wahren. Deshalb sind transaktionale Datenbanken in der Regel normalisiert: Jede Information wird nur einmal gespeichert, und eine Aktualisierung betrifft nur eine einzige Zeile statt fünf Kopien.
Seit der Prägung des Begriffs hat sich die Welt weiterentwickelt. Heute ist es einfach, Daten in nicht-relationalen Datenbanken zu speichern, von denen die meisten nur einige der vier ACID-Prinzipien erfüllen. Je nach Anwendungsfall ist es absolut sinnvoll, zugunsten von Geschwindigkeit oder Skalierbarkeit auf das eine oder andere Prinzip zu verzichten.
Stellen Sie sich vor, Sie speichern „Likes“ für einen Beitrag in einem sozialen Netzwerk. Muss die Anzahl zu 100 Prozent korrekt sein? Oder ist es ein akzeptabler Preis für eine schnellere Antwortzeit bei Millionen von Nutzern, wenn 995 statt 998 Likes angezeigt werden?
Da OLTP für Online Transaction Processingsteht, ist der Begriff nicht an relationale Datenbanken oder gar an vollständig ACID-konforme Systeme gebunden. Er bezieht sich darauf, wie ein Speicher genutzt wird. Wenn Sie eine Dokumentendatenbank wie MongoDB verwenden, um das Tagesgeschäft einer Social-App abzuwickeln – etwa um Nutzer zu registrieren oder Likes zu speichern –, ist es durchaus angemessen, dies als OLTP zu bezeichnen.
Dies ist der wichtigste Punkt, den man über diesen Begriff verstehen sollte. OLTP beschreibt ein Nutzungsmuster, keine Produktkategorie. PostgreSQL ist keine „OLTP-Datenbank“. Es ist eine Datenbank, die auf eine OLTP-Art genutzt wird. Dieselbe Engine, die auf ein Sternschema angesetzt wird, um ein Jahr an Historie zu aggregieren, betreibt OLAP. Anbieter haben natürlich ein Interesse daran, diese Grenzen zu verwischen. Ein Nutzungsmuster lässt sich nicht verkaufen. Eine Produktkategorie schon.
OLAP steht für Online Analytical Processingund bezeichnet in der Regel Datenbanken, die Daten für Analysen und Entscheidungsfindungen speichern und verwalten.
OLAP ist eng verknüpft mit Business Intelligence (BI), einer Software zur Bereitstellung von Anwendungen für Geschäftsanalysen. Das Ziel von BI ist es, Entscheidungsträgern die Möglichkeit zu geben, Daten abzufragen und zu untersuchen, ohne die IT-Abteilung einbeziehen zu müssen.
Kurz gesagt: OLAP analysiert Daten, damit Sie Entscheidungen treffen können.
Der eigentliche Fortschritt bestand darin, Berichte spontan zu erstellen. Es ist nicht mehr nötig, die IT um einen benutzerdefinierten Bericht zu bitten oder spezifische Berichte vorab zu erstellen. Ein BI-System kann Fragen beantworten, von denen die Entwickler nicht einmal wussten, dass sie gestellt werden könnten.
BI-Systeme organisieren Daten in einem Hypercube, auch OLAP-Würfel genannt: ein mehrdimensionales Array, bei dem jede Dimension eine Analyseachse darstellt, wie etwa Zeit, Produkt oder Region, und jede Zelle einen voraggregierten Messwert enthält. Da diese Aggregationen entlang der Achsen im Voraus berechnet werden, kann ein Benutzer vom Jahresumsatz zum Umsatz nach Produkt und Monat wechseln, ohne auf einen neuen Scan warten zu müssen. Das Wechseln zwischen solchen Detailebenen, von einer Jahressumme bis hinunter zu einer einzelnen Woche, nennen Analysten Drill-Down. Genau so erstellt ein kaufmännischer Leiter seinen eigenen Bericht, ohne dass ein Techniker involviert ist.
OLAP kann auch auf relationalen Datenbanken (wie z. B. MySQL) implementiert werden, eine Technik, die ROLAP (Relational OLAP) genannt wird. Dafür wird das Schema bewusst denormalisiert in eine Stern- oder Schneeflockenform gebracht: eine zentrale Tabelle mit gemessenen Ereignissen, wie etwa Bestellungen, umgeben von beschreibenden Tabellen für die gemessenen Objekte, wie Kunde, Produkt und Datum.
Bei der Datenanalyse können wir mit redundanten Daten leben. Was zählt, ist die Fähigkeit, durch die Dimensionen zu navigieren. Denormalisierte Schemata reduzieren die Anzahl der Joins, die eine analytische Abfrage auflösen muss. Genau deshalb eignen sie sich für Aggregationen und Drill-Downs – und genau deshalb wäre dasselbe Design in einem transaktionalen System ein Nachteil, da jede Dublette eine weitere Zeile ist, die synchron gehalten werden muss.
OLTP liefert Ihnen eine sofortige Aufzeichnung Ihrer Geschäftsaktivitäten. OLAP verwandelt die zusammengeführten Daten dieser Aufzeichnungen in wertvolle Erkenntnisse. Beide ergänzen sich, denn die Qualität der OLAP-Erkenntnisse hängt immer von der Datenpipeline ab, die durch OLTP gespeist wird.
| OLTP | OLAP | |
|---|---|---|
| Zweck | Operatives Geschäft ausführen: Transaktionen fortlaufend erfassen | Geschäft verstehen: Analysieren, was bereits passiert ist |
| Typische Abfrage | Lesen oder Schreiben einzelner Zeilen anhand einer ID | Scannen und Aggregieren von Millionen von Zeilen über mehrere Dimensionen hinweg |
| Antwortzeit | Millisekunden. Benutzer warten direkt am Bildschirm | Sekunden bis Minuten. Ein Dashboard oder Bericht wird erstellt |
| Schreibmuster | KONTINUIERLICHE kleine Schreibzugriffe, hohe Nebenläufigkeit | Massen-Ladevorgänge oder CDC-Streams, stapelweise oder in Nahezu-Echtzeit |
| Nebenläufigkeit | Tausende gleichzeitige Benutzer, meist kurze Transaktionen | Dutzende bis Hunderte von Analysten, die lange Abfragen ausführen |
| Schema-Design | Normalisiert, sodass jeder Fakt genau einmal gespeichert wird | Denormalisiertes Stern- oder Schneeflockenschema, optimiert für Aggregationen |
| Speicherlayout | Zeilenorientiert: Der gesamte Datensatz wird zusammen gelesen | Spaltenorientiert: Es werden nur die Spalten gelesen, die eine Abfrage benötigt |
| Datenumfang | Aktueller operativer Zustand, Historie von Tagen oder Wochen | Vollständige Historie, oft jahrelang, über mehrere Quellsysteme hinweg |
| Datenquelle | Direkt von Anwendungen und Benutzern erfasst | Aus OLTP-Systemen und von Drittanbietern über ETL/ELT/CDC geladen |
| Konsistenz | ACID-Transaktionen; Korrektheit ist nicht verhandelbar | Konsistent mit der Quelle zum Zeitpunkt des letzten Ladevorgangs |
| Sicherung und Wiederherstellung | Fortlaufend, mit Point-in-Time-Recovery. Datenverlust bedeutet Geschäftsverlust | Aus der Quelle neu ladbar, daher erfolgt die Wiederherstellung durch Neuaufbau |
| Typische Produkte | PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, DynamoDB | Snowflake, BigQuery, Redshift, Databricks, ClickHouse, DuckDB |
| Zielgruppe | Kunden und operatives Personal über eine Anwendung | Analysten, BI-Tools und Führungskräfte über Dashboards und Berichte |
Der technische Unterschied ist gut dokumentiert. Der wirtschaftliche hingegen selten – dabei entscheidet genau dieser darüber, ob sich die Trennung lohnt.
Die Kosten, wenn man nicht trennt. Analysen direkt auf der Produktionsdatenbank auszuführen, ist bei jungen Produkten der Standard – und das funktioniert so lange, bis es eben nicht mehr funktioniert. Das Fehlerbild ist spezifisch: Ein Analyst führt eine Abfrage aus, die ein Jahr an Bestellungen scannt, diese Abfrage blockiert Ressourcen oder verbraucht den verfügbaren Festplattendurchsatz, und die Checkout-Latenz steigt für jeden Kunden auf der Website. Ihr Ausfall wurde durch einen Bericht verursacht. Read-Replicas zögern dies hinaus und sind der richtige erste Schritt, aber sie lösen das Problem nicht, da die Replica immer noch ein Schema verwendet, das für Transaktionen statt für Aggregationen ausgelegt ist, und zudem jeden Schreibvorgang der Primärdatenbank repliziert.
Hier ist die Abfrage, die den Schaden anrichtet: eine Aggregation über das gesamte Jahr, die auf dieselbe Tabelle zugreift, in die der Checkout schreibt:
-- Run against the primary, mid-afternoon, while customers are checking out.
-- Row store, no covering index: this scans ~N million live rows and
-- competes with the checkout for buffer pool and disk I/O.
SELECT region,
date_trunc('month', created_at) AS month,
sum(total) AS revenue
FROM orders -- the table the till also writes to
WHERE created_at >= now() - interval '12 months'
GROUP BY region, month
ORDER BY region, month;Dieselbe Abfrage gegen ein spaltenorientiertes Data Warehouse liest nur die drei benötigten Spalten und berührt den Checkout zu keinem Zeitpunkt. Das ist das gesamte Argument für ein zweites System, zusammengefasst in einem Satz.
Die Kosten der Trennung. Eine separate Analyseumgebung ist nicht nur eine Warehouse-Lizenz. Es ist eine Pipeline, die gebaut, überwacht und bei jeder Änderung des Quellschemas repariert werden muss. Es ist eine zweite Kopie Ihrer Daten mit eigenen Zugriffskontrollen und Aufbewahrungsregeln. Und es ist ein Abgleichproblem, sobald das Dashboard am ersten Morgen andere Zahlen anzeigt als der operative Bericht. Cloud-Warehouses sind günstig im Start und werden nach Verbrauch statt nach Kapazität abgerechnet: Laut den veröffentlichten Preisen von Google Cloud kostet BigQuery On-Demand-Abfragen mit 6,25 US-Dollar pro gescanntem TiB (wobei das erste TiB pro Monat kostenlos ist), und die Dokumentation von Snowflake beziffert Snowflake Rechenleistung auf sekundengenaue Abrechnung, mit einem Minimum von 60 Sekunden bei jedem Start eines Warehouses. Das bedeutet, die Rechnung richtet sich nach der Dashboard-Nutzung, nicht nach dem Datenvolumen. Sie steigt, wenn die Akzeptanz wächst, nicht wenn die Datenmenge zunimmt. (Preise geprüft am 12. August 2026 gemäß der Dokumentation von Google Cloud und Snowflake. Überprüfen Sie die aktuellen Tarife vor einer Angebotserstellung.)
Wann sich die Trennung auszahlt. Der Auslöser ist selten das Datenvolumen. Meistens ist es einer von drei Faktoren: Die analytische Last beginnt die Produktionsleistung zu beeinträchtigen, es besteht die Notwendigkeit, Daten über Systeme hinweg zu verknüpfen, die keiner einzelnen Anwendung gehören (CRM, Abrechnung, Support), oder es gibt eine Berichtsanforderung, die einen längeren Zeitraum abdeckt, als die operative Datenbank vorhalten sollte.
War dieser Artikel hilfreich? Dann gefallen Ihnen vielleicht auch diese!
Wenn wir einen Daten-Stack bewerten, entscheiden drei Fragen über das Ergebnis. Es lohnt sich, diese zu stellen, bevor man sich für ein Tool entscheidet. Meistens enden sie mit der Empfehlung, noch zu warten, da die kostengünstigere Option noch nicht ausgeschöpft ist.
Ein wiederkehrendes Muster bei den von uns geprüften Stacks: Ein Data Warehouse wird für eine einzige Berichtsanforderung erstellt und dann sich selbst überlassen. Wenige Monate später stimmen die Zahlen nicht mehr mit dem operativen System überein, und das Unternehmen ist stillschweigend dazu übergegangen, wieder Tabellenkalkulationen zu exportieren. Die Technologie war nie der limitierende Faktor.
Wenn Sie vor dieser Entscheidung stehen: Unsere Teams begleiten diesen Prozess im Rahmen unserer KI- und Datenprojekte, und wie das in der Praxis aussieht, zeigen unsere Fallstudien.
Wenn man zum ersten Mal mit OLTP und OLAP in Berührung kommt, stellt sich schnell die Frage, welches System besser ist. Das ist jedoch der falsche Ansatz. Die entscheidende Frage lautet: Wie ergänzen sie sich gegenseitig?
Wir wissen nun:
Genau so setzen erfolgreiche Unternehmen diese Systeme ein. Wir haben diese Aufteilung selbst in der Produktion angewendet. Bei Confinze, einer Finanz-Outsourcing-Plattform für SaaS-Startups, nutzten wir PostgreSQL als operative Datenbank für die Anwendung und übertrugen die Analysedaten in ein Snowflake-Data-Warehouse, wobei Recharts und Nivo die kundenorientierten Berichte erstellten. Postgres wickelte die Transaktionen ab; Snowflake lieferte die Antworten auf unsere Fragen. Diese Architektur ermöglichte dem Kunden eine Bindungsrate von 85 Prozent, und genau diese Zwei-System-Struktur beschreibt der Rest dieses Artikels.
Daten aus operativen Systemen – wie einer HR-Datenbank, einem CRM oder einem Abrechnungssystem – werden gesammelt und durch einen Prozess namens Extract, Transform and Load (ETL)aufbereitet. Beim Extrahieren werden die Datensätze aus den jeweiligen Quellen abgerufen. Beim Transformieren werden sie in ein einheitliches Format gebracht. Beim Laden werden sie in das Warehouse geschrieben und für die Analyse strukturiert. Die Zusammenführung verschiedener OLTP-Quellen in einem einzigen Warehouse ermöglicht erst die systemübergreifende Analyse.
Diese Reihenfolge ist nicht in Stein gemeißelt. Viele Teams setzen mittlerweile auf ELT (Extract, Load, Transform). Dabei werden die Rohdaten zuerst geladen und erst innerhalb des Warehouses transformiert. Da Cloud-Warehouses leistungsstark genug für diese Aufgaben sind, bietet das Speichern der Rohdaten zudem den Vorteil, dass fehlerhafte Transformationen korrigiert werden können, ohne erneut auf die Quelle zugreifen zu müssen.
Auch der Zeitplan hat sich gewandelt. Die nächtliche Stapelverarbeitung ist nicht mehr die einzige Option: Das gängige Muster für 2026 kombiniert eine OLTP-Engine mit einer OLAP-Engine mittels Change Data Capture (CDC). Dabei werden Schreibvorgänge mithilfe von Tools wie Debezium, PeerDB oder Aurora Zero-ETL innerhalb von Sekunden statt Stunden repliziert. So arbeiten die Analysten stets mit aktuellen Daten und können zeitnah Entscheidungen treffen, ohne den operativen Betrieb zu stören. Wenn Sie darauf aufbauen möchten, erfahren Sie in unserem Artikel über Data Science für Unternehmen , was passiert, sobald die Analysedaten bereitstehen.
Das strikte Zwei-System-Modell ist nicht mehr die einzige Option. Es lohnt sich daher zu betrachten, was sich tatsächlich verändert hat und was nicht.
pg_duckdb Erweiterung führt analytische Abfragen über Ihre Postgres-Tabellen mithilfe einer vektorisierten Engine aus – effektiv ein HTAP-Setup für Workloads mittlerer Größe, ganz ohne den Betrieb eines Data Warehouse.Die Frage ist also nicht mehr, ob Sie irgendwann beide Funktionen benötigen werden. Die Frage ist, wie lange Sie das zweite System verantwortungsvoll hinauszögern können – und zunehmend auch, ob eine hybride Engine es Ihnen ermöglicht, diesen Schritt deutlich länger aufzuschieben, als es noch vor einem Jahrzehnt möglich gewesen wäre.
OLTP-Systeme erfassen Transaktionen in Echtzeit und verarbeiten viele kleine Lese- und Schreibvorgänge im Millisekundenbereich. OLAP-Systeme analysieren diese Transaktionen im Nachhinein, indem sie große Datenmengen scannen und aggregieren, um geschäftliche Fragen zu beantworten. OLTP hält das Geschäft am Laufen; OLAP liefert die Erkenntnisse dazu.
Weder noch. SQL ist eine Abfragesprache, die für beides verwendet wird. Der Unterschied liegt im Design und der Nutzung der Datenbank, nicht in der Sprache, mit der man sie abfragt. PostgreSQL und Snowflake verwenden beide SQL, aber das eine ist für kurze Transaktionen optimiert, das andere für umfangreiche Datenanalysen.
Snowflake ist ein OLAP-System, ein Cloud-Data-Warehouse, das für analytische Abfragen über große Datensätze konzipiert ist. Es speichert Daten spaltenbasiert statt zeilenbasiert und skaliert seine Abfrage-Engine unabhängig vom Speicher. Es ist nicht für hochgradig gleichzeitige transaktionale Workloads ausgelegt und daher die falsche Wahl für einen Checkout-Prozess. (Die Funktion „Hybrid Tables“ bietet zwar eine Zeilenspeicher-Option für transaktionale Workloads, das Kernprodukt bleibt jedoch analytisch.)
Ja, bis zu einem gewissen Grad. HTAP-Plattformen sind explizit für beides ausgelegt, und eine mittelgroße PostgreSQL-Instanz kann beides bewältigen, sofern die analytische Last gering ist. Die Grenze ist die Ressourcenkonkurrenz: Sobald analytische Abfragen die Latenz der Transaktionen beeinträchtigen, müssen die Workloads getrennt werden – etwa durch ein Read-Replica, eine eingebettete spaltenorientierte Engine wie DuckDB oder ein dediziertes Warehouse.
Nicht unbedingt. Wenn sich Ihre Berichte auf ein System beziehen und das Datenvolumen überschaubar ist, reicht in der Regel ein Read-Replica aus. Ein Warehouse wird notwendig, wenn Sie Daten aus verschiedenen Systemen zusammenführen müssen, mehr Historie benötigen, als die operative Datenbank speichern sollte, oder die Produktion vor analytischer Last schützen wollen.
Beide Verfahren verschieben Daten aus operativen Systemen in einen analytischen Speicher. Bei ETL werden die Daten vor dem Laden transformiert, was das Warehouse sauber hält, aber bei einem Transformationsfehler einen erneuten Zugriff auf die Quelle erfordert. ELT lädt zunächst Rohdaten und transformiert diese innerhalb des Warehouses, was zwar mehr Speicherplatz verbraucht, aber eine erneute Verarbeitung ohne erneute Extraktion ermöglicht.
Nein. Ein Data Lake speichert Rohdateien in ihrer ursprünglichen Form ohne erzwungenes Schema. Ein OLAP-Warehouse speichert modellierte, abfragbare Tabellen. Viele Unternehmen nutzen beides: den Data Lake als Landezone und das Warehouse als die Ebene, die von Analysten tatsächlich abgefragt wird.
Zwei Begriffe, eine Beziehung, kaum echter Wettbewerb zwischen ihnen.
Jeden Tag werden neue Daten erfasst. Doch Daten allein entscheiden nichts. Deshalb organisieren und analysieren wir sie, um handlungsrelevante Erkenntnisse zu gewinnen. Aus diesem Grund verfügt ein Unternehmen in der Regel über zwei Arten der Datenverarbeitung: OLTP und OLAP.
Zurück zum Laden: Die Kasse muss stimmen, sonst stimmt der Tagesumsatz nicht. Das Kassenbuch muss lesbar sein, sonst lässt sich aus dem Jahr nichts lernen. OLTP garantiert, dass die Vorgänge korrekt erfasst werden; OLAP ermöglicht es, die Bedeutung dieser Aufzeichnungen zu verstehen. Die praktische Entscheidung lautet nie, welche der beiden man wählt. Es geht vielmehr darum, ab wann sich das zweite System betriebswirtschaftlich lohnt und wer dafür verantwortlich ist, sobald es existiert.
Wägen Sie diese Entscheidung für Ihren eigenen Stack ab? Sprechen Sie mit unserem Team. Wir sehen uns gerne an, was Sie bereits im Einsatz haben, und geben Ihnen eine ehrliche Einschätzung, ob Sie bereits ein Data Warehouse benötigen.
CEO bei Imaginary Cloud und Co-Autor des Buches Product Design Process. Ich mag gutes Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
LinkedIn
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
.webp)
