WISSEN > OBJECT STORAGE > OBJECT STORAGE WIRD DATENPLATTFORM
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Object Storage wird zur Datenplattform
Die neue Rolle zwischen Archiv, Cyber Resilience und KI
Das sollten Sie mitnehmen:
- Rollenwechsel.
Forrester und GigaOm beschreiben Object Storage übereinstimmend nicht mehr als reine Kapazitätsschicht, sondern als aktive Datenplattform.
- Datenfundament statt I/O-Pfad.
Eine Object-Plattform kann die dauerhafte Heimat der Unternehmensdaten sein, ohne für jeden Verarbeitungsschritt der optimale Zugriffspfad zu sein.
- Bindung oberhalb von S3.
Tabellen-, Vektor- und Beschleunigungsfunktionen sind herstellerspezifisch und binden stärker als das S3-Protokoll selbst.
- Doppelrolle.
Dieselbe Plattform trägt aktive Workloads und Unveränderbarkeit, was Mandantentrennung, IAM und Auditierung deutlich wichtiger macht.
- Wirtschaftlicher Rahmen.
Steigende Medienpreise, Energiebedarf und Stellfläche machen Konsolidierung attraktiver, ersetzen aber keine Tiering-Entscheidung.
Object Storage wird zur Datenplattform
Inhaltsverzeichnis
- Was die Analystenberichte belegen – und was sie offenlassen
- Der entscheidende Wandel ist nicht S3, sondern die Entkopplung von Daten und Compute
- Vom Data Lake zum ausführbaren Datenbestand
- Warum „Primary Storage für AI" technisch zu pauschal bleibt
- Die zweite neue Rolle: Object Storage als Anker der Cyber Resilience
- Konsolidierung verkleinert die Zahl der Systeme und vergrößert die Failure Domain
- S3-Kompatibilität reicht als Auswahlkriterium nicht mehr
- Steigende Speicherkosten sprechen für Konsolidierung, nicht dagegen
- Energie, Kühlung und Stellfläche gehören in dieselbe Rechnung
- Vom Storage Lifecycle zum Data Lifecycle
- Was das für verteilte Umgebungen bedeutet
- Drei Fragen, die vor der Produktauswahl zu klären sind
- Fazit
- Quellen
Object Storage wurde lange über eine einfache Gleichung eingeordnet: sehr große Datenmengen, hohe Haltbarkeit, vergleichsweise geringe Kosten – dafür weniger geeignet für aktive, performancekritische Workloads. Backup, Archiv und Medienarchive waren deshalb die typischen Einsatzfelder.
Diese Einordnung verliert an Aussagekraft. Zwei Analystenberichte aus dem Jahr 2026 beschreiben denselben Wandel aus unterschiedlicher Perspektive, und beide kommen zu dem Ergebnis, dass Object Storage näher an produktive Anwendungen rückt. Interessanter als die Berichte selbst ist jedoch die Frage, warum diese Verschiebung gerade jetzt stattfindet. Die grundlegende Architektur von Object Storage ist nicht neu. Neu ist, dass mehrere Entwicklungen gleichzeitig wirken: Unternehmensdaten wachsen überwiegend außerhalb klassischer Datenbanken, KI benötigt große dauerhaft verfügbare Datenbestände, S3 hat sich als universeller Datenzugriff etabliert, Object-Plattformen integrieren zusätzliche Datenservices, und Cyber Resilience zwingt Unternehmen dazu, Daten länger, unveränderbarer und unabhängiger von einzelnen Anwendungen zu halten.
Damit verändert sich die eigentliche Architekturfrage. Sie lautet nicht mehr, welche Daten sich auf Object Storage auslagern lassen, sondern welche Unternehmensdaten langfristig auf einer persistenten Datenplattform liegen sollten, von der unterschiedliche Anwendungen und Compute-Systeme konsumieren. Das ist eine wesentlich größere Rolle.
Was die Analystenberichte belegen – und was sie offenlassen
Forrester hat im zweiten Quartal 2026 eine Wave für Object Storage Solutions vorgelegt. Analyst Brent Ellis beschreibt darin den Übergang von günstigem Cold Storage zu einer aktiven Primärplattform und argumentiert, dass Cloud-native Workloads wie Serverless und Kubernetes von Object Storage abhängen und die Technik zur De-facto-Plattform für KI werde. Bewertet wurden zwölf Anbieter. Als Leader führt Forrester NetApp, Everpure, Nutanix und VAST Data; Dell, Scality, AWS, Hitachi Vantara, HPE und Huawei gelten als Strong Performer, DDN und Alibaba Cloud als Contender.
Der GigaOm Radar for Object Storage v7 zeichnet ein deutlich breiteres Bild. Er untersucht 27 Lösungen, elf davon als Leader, fünfzehn als Challenger und eine als Entrant. Bemerkenswert ist die Verteilung entlang der zweiten Achse: 26 der 27 Anbieter ordnet GigaOm als Platform Play ein, lediglich Seagate als reinen Feature Play – und zwar ausdrücklich als bewusste Fokussierung auf ein Storage-as-a-Service-Modell, nicht als Rückstand. Auch die Table Stakes des Marktes zeigen, wie weit die Basis inzwischen reicht: Access Control, Indexing und Search, Data Protection, Verschlüsselung, Geo-Replikation, Scale-out-Architektur sowie S3 und weitere Protokolle gelten als selbstverständlich.
Zwei weitere Beobachtungen aus demselben Report sind aufschlussreich. Das untersuchte Feld ist gegenüber der Vorversion von 22 auf 27 Lösungen gewachsen, trotzdem tritt nur ein einziger echter Neueinsteiger auf – wer in diesem Markt mitspielt, bringt Enterprise-Funktionalität von Beginn an mit. Gleichzeitig ist die Zahl der Outperformer von fünf auf zwei gefallen. GigaOm begründet das damit, dass KI-orientierte Funktionen den Charakter von Differenzierungsmerkmalen verlieren und zur Grundausstattung werden.
An dieser Stelle ist Zurückhaltung angebracht. Beide Berichte beschreiben zunächst eine Anbieterlandschaft, nicht eine Architekturentscheidung. Wir lesen die Zahl von 26 Platform Plays deshalb nicht als Beleg dafür, dass 26 belastbare Datenplattformen existieren, sondern als Beleg dafür, dass nahezu der gesamte Markt dasselbe Problem adressiert: Unternehmen wollen Daten nicht mehr für jede neue Anwendung erneut verschieben und duplizieren. Ob ein einzelnes Produkt diesen Anspruch einlöst, entscheidet sich in der Praxis an Themen, die eine Radar-Position nicht abbildet – an Metadatenverhalten unter Last, an der Qualität der Mandantentrennung, am Verhalten bei Teilausfällen.
Hinzu kommen methodische Einschränkungen, die für die Interpretation wesentlich sind. Forresters Feld ist klein, weil die Aufnahme unter anderem mindestens 100 Millionen US-Dollar Jahresumsatz mit Object-Storage-Produkten voraussetzte; etablierte Spezialisten wie Cloudian und MinIO fehlen deshalb ebenso wie Quantum und DataCore, IBM und Oracle wurden ausgeschlossen, AWS und Hitachi Vantara nur auf Basis eigener Recherche bewertet. Der GigaOm-Report wiederum wird über eine Registrierungsseite von Hitachi Vantara verteilt, und Hitachi Vantara ist darin selbst als Leader und Fast Mover geführt. Keine dieser Beobachtungen entwertet die Berichte. Sie begründen aber, warum wir Anbieterplatzierungen aus solchen Reports in Architekturprojekten grundsätzlich nicht als Auswahlkriterium verwenden, sondern ausschließlich die beschriebene Marktrichtung.
Und diese Richtung ist eindeutig. Sie lässt sich unabhängig von jeder Platzierung nachvollziehen.
Der entscheidende Wandel ist nicht S3, sondern die Entkopplung von Daten und Compute
Object Storage besitzt seit Langem eine Eigenschaft, die erst durch Cloud, Analytics und KI strategisch relevant geworden ist: Die Datenhaltung ist nicht an einen bestimmten Server, ein Filesystem oder eine Applikation gebunden. Ein Objekt wird über einen Schlüssel innerhalb eines Buckets adressiert, Anwendungen greifen über APIs darauf zu, und Compute und Storage lassen sich dadurch getrennt skalieren und erneuern.
Diese Entkopplung passt zu einer IT-Landschaft, in der der Lebenszyklus der Daten zunehmend länger ist als der Lebenszyklus der Anwendungen, die darauf zugreifen. Ein Trainingscluster kann nach drei Jahren ersetzt werden, ein Analytics-Framework kann wechseln, eine RAG-Plattform kann neu aufgebaut werden. Die zugrunde liegenden Dokumente, Bilder, Video-, Sensor- oder Forschungsdaten sollen dagegen möglicherweise Jahrzehnte bestehen bleiben. Genau hier verändert sich die strategische Rolle des Speichers: Object Storage entwickelt sich vom Zielsystem einer Anwendung zum persistenten Datenfundament mehrerer Anwendungen.
[BILD] Schichtdarstellung: dauerhafte Object-Datenbasis unten, darüber wechselnde Compute- und Anwendungsschichten mit unterschiedlichen Lebenszyklen
Vom Data Lake zum ausführbaren Datenbestand
Der klassische Data Lake hat dieses Ziel bereits verfolgt. Große Mengen unterschiedlich strukturierter Daten werden zentral gehalten und anschließend von Analytics-Systemen verarbeitet. Die aktuelle Entwicklung geht jedoch einen Schritt weiter, weil Object Storage Funktionen erhält, die früher oberhalb des Speichers lagen.
Amazon S3 Tables speichert Tabellen im Apache-Iceberg-Format innerhalb eines Table Buckets und übernimmt die Pflege dieser Tabellen durch automatische File Compaction und Snapshot Management. Über die Integration mit dem AWS Glue Data Catalog können Analytics-Dienste wie Athena und Redshift die Tabellen automatisch erkennen und darauf arbeiten. Mit S3 Vectors geht AWS noch weiter: Neben klassischen Objekten lassen sich Vektoren in eigens dafür vorgesehenen Vector Buckets speichern und per Ähnlichkeitssuche abfragen. Das Angebot ist seit Dezember 2025 allgemein verfügbar und wurde im März 2026 auf insgesamt 31 Regionen ausgeweitet; AWS positioniert es ausdrücklich für AI Agents, Inferenz, Retrieval-Augmented Generation und semantische Suche und hat es nativ in Bedrock Knowledge Bases eingebunden.
Diese Bewegung ist inzwischen auch Gegenstand ausdrücklicher Analystenempfehlungen. Gartner rät Infrastrukturverantwortlichen, für KI- und RAG-Umgebungen auf manuelle ETL-Strecken zu verzichten und Metadaten-Indexierung, semantisches Tagging und Vektorisierung möglichst dort auszuführen, wo die Daten bereits liegen. Begründet wird das mit Egress-Kosten, Transportlatenz und Compliance-Risiken jeder zusätzlichen Datenbewegung.
Das ist architektonisch relevant. Der Object Store enthält dann nicht mehr ausschließlich Originaldaten, sondern potenziell Originaldaten, Tabellenstrukturen, Metadaten, Vektorrepräsentationen, Lifecycle-Informationen und Governance-Regeln nebeneinander. Die Grenze zwischen Storage und Datenplattform wird dadurch unschärfer, und die architektonische Grundidee kehrt sich um: Compute kommt zu den Daten, statt Daten für jeden Compute-Stack erneut zu kopieren.
Warum „Primary Storage für AI" technisch zu pauschal bleibt
Aus der Beobachtung, dass Object Storage für KI wichtiger wird, entsteht schnell die These, Object Storage werde der neue Primary Storage für KI. Das ist zu pauschal, und die Unterscheidung ist keine Spitzfindigkeit.
AI-Workloads besitzen keinen einheitlichen I/O-Charakter. Ein Data Lake mit sehr großen Objekten stellt andere Anforderungen als Millionen kleiner Trainingsdateien, als Checkpoint-Schreibvorgänge, hochparallele Datenloader oder latenzkritische Inferenz. Hoher aggregierter S3-Durchsatz beantwortet deshalb nicht die Frage, ob ein Storage-System einen GPU-Cluster effizient versorgen kann. Genau diese Diskrepanz sehen wir in Projekten regelmäßig: Ein System erreicht in synthetischen Durchsatzmessungen überzeugende Werte und fällt in der Trainingsschleife zurück, weil die Metadatenoperationen und nicht der Datenpfad limitieren.
Dass die Hersteller an dieser Grenze arbeiten, ist unstrittig. NVIDIA GPUDirect Storage ermöglicht einen direkten DMA-Datenpfad zwischen Storage und GPU-Speicher und vermeidet den zusätzlichen Umweg über einen Bounce Buffer im CPU-Speicher; dadurch sinken Latenz und CPU-Last, und der erreichbare Durchsatz steigt. Für Object Storage existiert mit cuObject inzwischen ein eigener API-Zweig. Parallel dazu bringen mehrere Anbieter S3 over RDMA in ihre Plattformen, um denselben Effekt für S3-Zugriffe zu erzielen. GigaOm führt den AI-optimierten Datenpfad – ausdrücklich unter Nennung von S3 over RDMA und GPUDirect Storage – inzwischen als eigenes Bewertungskriterium, allerdings noch in der Kategorie der Emerging Features.
Bei S3 over RDMA lohnt ein genauer Blick, weil der Begriff einen Standard suggeriert, den es nicht gibt. IBM unterstützt die Funktion in Storage Scale ab Version 6.0.1, MinIO führte sie in AIStorzunächst als Private Preview ein, VAST Data beschreibt ein Modell, bei dem die Steuerungsebene weiterhin über HTTP und TCP läuft und nur die Objektdaten über RDMA transportiert werden. Es handelt sich also um herstellerspezifische Implementierungen mit unterschiedlichen Voraussetzungen an Netzwerk und Client. Wer eine Beschaffungsentscheidung auf diese Funktion stützt, sollte das im Bewusstsein tun, dass er sich damit an eine konkrete Plattform bindet.
Die tragfähige Unterscheidung lautet deshalb: Object Storage kann die dauerhafte Datenbasis einer AI-Architektur sein, ohne für jeden Verarbeitungsschritt der optimale I/O-Layer zu sein. Eine sinnvolle Architektur besteht in unseren Projekten regelmäßig aus einer dauerhaften Object-Schicht und einer zusätzlichen hochperformanten Processing- oder Cache-Schicht. Die Datenbasis bleibt stabil, während der Zugriffspfad abhängig vom Workload gewählt wird. Diese Aufteilung ist die eigentliche Entscheidung – nicht die Frage „File oder Object".
Die weitergehende Behandlung der Zugriffspfade für Trainings- und Inferenzumgebungen findet sich in [Platzhalter: Titel des Artikels zu High-Performance Data Access].
Die zweite neue Rolle: Object Storage als Anker der Cyber Resilience
Die Entwicklung zur Datenplattform wäre allein bereits relevant. Gleichzeitig übernimmt Object Storage aber eine zweite Rolle, die zunächst im Widerspruch zur ersten zu stehen scheint. Je aktiver Daten genutzt werden, desto größer wird ihre Angriffsfläche – und ausgerechnet dieselbe Schicht soll die unveränderbare Kopie halten.
Technisch ist die Grundlage vorhanden. Versionierung und Object Lock ermöglichen es, Datenversionen für einen definierten Zeitraum gegen Veränderung und Löschung zu schützen, unabhängig von den Rechten der zugreifenden Anwendung. GigaOm empfiehlt inzwischen, Object Lock im Compliance Mode grundsätzlich als Anforderung in Ausschreibungen aufzunehmen.
Die Erwartungshaltung verschiebt sich dabei gerade spürbar. Gartner geht davon aus, dass 2029 sämtliche Storage-Produkte Cyberstorage-Funktionen zur aktiven Abwehr enthalten werden; Anfang 2026 lag der Anteil bei rund einem Viertel. Gemeint ist ausdrücklich mehr als nachgelagerte Wiederherstellung: Erkennung auffälliger Verschlüsselungsmuster im Datenpfad selbst und automatisch ausgelöste unveränderbare Snapshots, statt einer Auswertung von Sicherungsständen Stunden nach dem Ereignis. Forrester argumentiert aus einer anderen Richtung ähnlich und leitet aus der Bindung der Daten an ihre Plattform ab, dass Security-, Compliance- und Souveränitätskontrollen möglichst dort implementiert werden sollten, wo die Daten liegen.
Damit entsteht eine bemerkenswerte Doppelrolle: Dieselbe Plattform soll aktive Datenbasis und dauerhafter Schutzpunkt sein. Strategisch ist diese Kombination attraktiv, weil Unternehmen für Analytics oder KI dann nicht zwangsläufig Daten aus einem geschützten Archiv herauskopieren und anschließend zwei Datenbestände getrennt verwalten müssen. Aus Betriebssicht ist sie anspruchsvoll, denn Unveränderbarkeit ist nur so belastbar wie das Rechtemodell, das sie konfiguriert. Wir achten in Projekten deshalb konsequent darauf, dass die Instanz, die Retention-Regeln setzt, eine andere ist als die, die Daten schreibt, und dass der Nachweis der Unveränderbarkeit nicht ausschließlich aus derselben Verwaltungsebene stammt, die im Angriffsfall kompromittiert sein könnte.
Die Detailbetrachtung der Immutability-Mechanismen und ihrer Grenzen ist Gegenstand von [Platzhalter: Titel des Artikels zu Cyber Resilience im Object Storage].
[BILD] Doppelrolle: identische Datenbasis, links aktive Zugriffspfade für Analytics und KI, rechts Retention- und Immutability-Pfad mit getrennter Rechteebene
Konsolidierung verkleinert die Zahl der Systeme und vergrößert die Failure Domain
Je mehr Anwendungen, Identitäten, Datenservices und automatisierte Pipelines unmittelbar auf dieselbe Plattform zugreifen, desto wichtiger werden IAM, Mandantentrennung, Auditierung und Governance. Die Plattform reduziert Datensilos, sie erhöht aber gleichzeitig die Bedeutung eines einzelnen Systems. Konsolidierung senkt die Infrastrukturkomplexität und vergrößert die potenzielle Failure Domain.
Das ist kein Argument gegen Konsolidierung, sondern eines für veränderte Betriebsstandards. Eine zentrale Object-Plattform benötigt andere Anforderungen an Zugriffskontrolle, Protokollierung und Wiederanlauf als ein isoliertes Backup-Target, das im Wesentlichen von einer einzigen Applikation beschrieben wird. In der Praxis unterschätzen Organisationen dabei weniger die technische Absicherung als die organisatorische Frage, wer Buckets, Policies und Schlüssel verantwortet, wenn plötzlich mehrere Fachbereiche gleichzeitig auf derselben Plattform arbeiten. Wo diese Zuständigkeit nicht geklärt ist, entsteht aus der Datenplattform sehr schnell wieder eine Sammlung faktischer Silos innerhalb eines Systems.
S3-Kompatibilität reicht als Auswahlkriterium nicht mehr
Vor einigen Jahren konnte S3-Kompatibilität ein Differenzierungsmerkmal sein. Heute ist sie Eintrittsvoraussetzung; GigaOm zählt S3-Unterstützung gemeinsam mit Scale-out, Verschlüsselung, Geo-Replikation und Zugriffskontrolle zu den Table Stakes des Marktes. Damit verschiebt sich die relevante Frage weg vom Protokoll und hin zu der Architektur, die sich oberhalb und unterhalb von S3 bildet – zu Daten- und Metadatenservices, Kubernetes-Integration, Event-Mechanismen, Lifecycle Management, globalen Namespaces, Performancepfaden, Immutability-Funktionen, Hybrid-Cloud-Anbindung sowie Identity- und Governance-Modellen.
Dabei ist selbst die S3-Kompatibilität weniger einheitlich, als der Begriff suggeriert. Forrester benennt bei mehreren bewerteten Plattformen fehlende oder abweichende Teile der S3-API ausdrücklich als Einschränkung der Portabilität – und zwar quer durch das Feld, von All-Flash-Systemen bis zu AI-orientierten Anbietern. „S3-kompatibel" beschreibt damit eine Familie ähnlicher Implementierungen, nicht eine garantierte Austauschbarkeit.
Auch Kubernetes zeigt diesen Wandel, allerdings anders, als es die Erzählung von der fortschreitenden Standardisierung nahelegt. Das Container Object Storage Interface, kurz COSI, verfolgt seit 2022 das Ziel, Object Storage ähnlich deklarativ in Kubernetes einzubinden, wie CSI es für File- und Block-Storage tut, und ausdrücklich auch das Ziel, Anwendungen von einzelnen Anbietern zu lösen. Eingeführt wurde COSI als Alpha-Feature in Kubernetes 1.25. Vier Jahre später befindet sich das Projekt weiterhin im Alpha-Stadium: Die aktuelle API-Version v1alpha2 ist als Pre-Release gekennzeichnet, mit ausdrücklichem Hinweis auf mögliche kompatibilitätsbrechende Änderungen. Bezeichnend ist, dass GigaOm COSI-Unterstützung ebenfalls noch unter den Emerging Features führt und nicht unter den Kernfunktionen. Wer heute auf COSI als Portabilitätsgarantie plant, plant auf eine Zusage, die noch nicht eingelöst ist.
Daraus folgt eine Konsequenz, die häufig übersehen wird: Ein standardisiertes Zugriffsprotokoll bedeutet nicht automatisch eine standardisierte Datenplattform. Eine Anwendung kann relativ einfach zwischen zwei S3-Endpunkten wechseln. Nutzt sie zusätzlich proprietäre Vektorindizes, integrierte Tabellenfunktionen, herstellerspezifische Beschleunigungspfade, Events oder Security-Funktionen, steigt die Bindung erheblich. Je intelligenter Object Storage wird, desto größer wird paradoxerweise die Bindung oberhalb der S3-API – und zwar genau in den Funktionen, die den Plattformcharakter überhaupt erst ausmachen.
[BILD] Schichtdiagramm: S3-API als portable Ebene, darüber Tabellen-, Vektor-, Event- und Beschleunigungsdienste mit jeweils herstellerspezifischer Ausprägung
Steigende Speicherkosten sprechen für Konsolidierung, nicht dagegen
Eine zentrale Datenplattform benötigt sehr viel Kapazität. Man könnte deshalb erwarten, dass steigende Storage-Kosten diese Entwicklung bremsen. Tatsächlich kann das Gegenteil eintreten.
Gartner fordert im Magic Quadrant for Enterprise Storage Platforms, für 2027 mit 250 bis 300 Prozent des Storage-Budgets von 2025 zu kalkulieren, begründet mit Engpässen und Preissteigerungen bei SSD-Flash, HDD und DRAM. Der Wert ist ausdrücklich eine Planungsannahme und kein prognostizierter individueller Preisaufschlag. Gartner erwartet, dass dieses verknappte Umfeld mindestens bis 2028 anhält, und rechnet damit, dass verbrauchsbasierte Bezugsmodelle bis 2029 etwa die Hälfte der lokalen Investitionsausgaben für Enterprise Storage ersetzen – gegenüber rund einem Viertel Anfang 2026. Auch das ist im Kern eine Reaktion auf Preisvolatilität.
Parallel dazu erwartet Gartner eine deutliche Konsolidierung unstrukturierter Daten: 2029 sollen mehr als 80 Prozent der lokal gespeicherten Daten auf gemeinsamen Plattformen liegen statt auf getrennten File- und Object-Systemen, gegenüber rund 50 Prozent im Jahr 2025. Für KI fällt die Bewegung noch stärker aus – rund 70 Prozent der Unternehmen sollen dann spezielle Storage-Tiers für großskalige Inferenz und Retrieval-Augmented Generation einsetzen, nach weniger als zehn Prozent Anfang 2026.
Bei der Konsolidierungszahl lohnt eine Lesehilfe. Gartner schließt aus der zugrunde liegenden Marktdefinition sowohl hyperkonvergente Lösungen als auch reine Public-Cloud-Dienste aus. Die Prognose beschreibt damit den Markt lokaler Plattformprodukte und trifft keine Aussage über verteilte Architekturen, die Daten über mehrere Standorte hinweg bereitstellen.
Diese beiden Erwartungen zusammen sind aufschlussreicher als jede einzelne für sich. Sie beschreiben keine Vereinheitlichung, sondern eine gemeinsame Datenbasis mit ausdifferenzierten Zugriffsschichten darüber. Genau das entspricht unserer Projekterfahrung: Der wirtschaftliche Effekt der Konsolidierung entsteht nicht dadurch, dass alle Daten auf demselben Medium liegen, sondern dadurch, dass Kapazitätsreserven, Lifecycle-Prozesse, Schutzmechanismen und Administration nur einmal vorgehalten werden müssen. Separate Speicherinseln für Backup, Archiv, Analytics und einzelne Anwendungen benötigen diese Ressourcen jeweils vollständig.
Zugleich verändert sich die Bedeutung der Transferkosten. Ein Archiv wird selten gelesen; dort dominieren die Kosten pro gespeichertem Terabyte. Eine aktive Datenplattform wird kontinuierlich gelesen, verarbeitet und möglicherweise zwischen Clouds oder Compute-Standorten bewegt. GigaOm beschreibt genau diesen Effekt als treibende Kraft hinter der Rückverlagerung datenintensiver Workloads aus der Public Cloud: Bei AI-Pipelines, die denselben Datenbestand über viele Trainingsdurchläufe hinweg wiederholt lesen, entfällt ein erheblicher Anteil der Gesamtkosten auf Transaktions- und Egress-Gebühren statt auf Kapazität. Ausschlaggebend ist dabei nicht eine Abkehr vom Cloud-Betriebsmodell, sondern die Ökonomie der Datenbewegung.
Damit werden Zugriffs-, API- und Egress-Kosten zu einem eigenständigen Planungsfaktor, und der Preis pro Terabyte verliert als Vergleichsgröße an Aussagekraft. Wir empfehlen deshalb, Kostenvergleiche für Object-Plattformen grundsätzlich auf Basis eines angenommenen Zugriffsprofils zu rechnen und nicht auf Basis des Speicherpreises.
Energie, Kühlung und Stellfläche gehören in dieselbe Rechnung
Kapazitätskonsolidierung ist immer auch eine Frage des Rechenzentrums. Eine zentrale Datenplattform verschiebt Last, Wärme und Stellfläche, und die Richtung dieser Verschiebung hängt maßgeblich von der Medienwahl ab. Flash-Kapazität reduziert Rack-Fläche und Kühlbedarf pro nutzbarem Terabyte deutlich, ist aber genau von den Preissteigerungen betroffen, die den Kostendruck überhaupt erst erzeugen. HDD-basierte Kapazität bleibt wirtschaftlich attraktiv, kostet dafür Fläche und Kühlleistung. Für eine Plattform, die über zehn Jahre hinweg wachsen soll, ist das keine Nebenrechnung.
Bemerkenswert ist, dass Gartner aus der Preisentwicklung nicht den Verzicht auf Flash ableitet, sondern eine präzisere Zuordnung von Medien zu Zugriffsprofilen: hochdichte QLC-Medien als Aufnahmeschicht für aktive Datenbestände, HDDs als kostengünstige Warm-Schicht, und eine anhaltende Relevanz von HDD und Tape bis 2030. Das ist genau die Tiering-Entscheidung, die eine Plattformkonsolidierung nicht ersetzt, sondern voraussetzt.
Regulatorisch ist der Rahmen dafür gesetzt. Das Energieeffizienzgesetz ist seit dem 18. November 2023 in Kraft und verpflichtet Rechenzentren unter anderem zu Effizienzanforderungen und zur Berichterstattung; eine Novelle hat im Juni 2026 das Kabinett passiert, das parlamentarische Verfahren war zum Redaktionsschluss nicht abgeschlossen. Unternehmen sollten die konkreten Zielwerte deshalb als beweglich behandeln, die Berichtspflicht selbst dagegen nicht.
Aus unserer Sicht wichtiger als der jeweils gültige Zielwert ist ein methodisches Problem, das die Debatte um die Kennzahl PUE durchzieht. PUE setzt den Gesamtenergiebedarf ins Verhältnis zur IT-Last. Wächst die IT-Last, weil zusätzliche Analytics- und KI-Workloads auf denselben Datenbestand zugreifen, kann sich der PUE-Wert verbessern, während der absolute Energieverbrauch deutlich steigt. Eine Konsolidierung auf eine gemeinsame Datenplattform lässt sich auf diese Weise energetisch gut aussehen lassen, ohne dass tatsächlich Energie eingespart wurde. Wir bestehen in Projekten deshalb darauf, den absoluten Verbrauch pro dauerhaft gespeichertem Terabyte und pro Zugriffsprofil zu betrachten und PUE ausschließlich als ergänzende Kennzahl zu führen.
Vom Storage Lifecycle zum Data Lifecycle
Die vielleicht wichtigste Konsequenz dieser Entwicklung liegt nicht im Storage selbst. Traditionell wurde Speicher nach Workloads geplant: Das ERP-System erhielt sein Storage-System, Backup ein zweites, Archiv ein drittes, Analytics ein viertes. Die Daten folgten dabei der Anwendung, und beim Anwendungswechsel folgte die Migration.
Eine datenorientierte Architektur dreht diese Beziehung teilweise um. Unternehmensdaten bilden eine dauerhafte Ebene, auf die Anwendungen, Analytics-Engines und AI-Systeme zugreifen. Der Lifecycle verschiebt sich damit von der Applikation zur Datenplattform, über der die Compute- und Anwendungsschichten wechseln. Object Storage ist für diese Rolle attraktiv, weil S3, horizontale Skalierung, Metadaten, Lifecycle Policies, Versionierung und Immutability viele der dafür benötigten Eigenschaften bereits mitbringen.
Genau deshalb ist die aktuelle Entwicklung mehr als eine weitere Evolutionsstufe der Speichertechnologie. Sie betrifft die Frage, welche Schicht einer Unternehmensarchitektur langfristig stabil bleiben soll.
Was das für verteilte Umgebungen bedeutet
Ein Aspekt kommt in beiden Analystenberichten kaum vor, ist in unseren Projekten aber häufig der wirtschaftlich entscheidende: die Anzahl der Standorte.
Die zitierten Marktanalysen betrachten Datenplattformen weitgehend als Produkt eines Herstellers im Rechenzentrum. Für Unternehmen mit verteilten Standorten stellt sich die Frage jedoch anders. Eine Umgebung, die an jedem Standort den vollständigen Datenbestand vorhält, skaliert ihre Medienkosten mit der Anzahl der Standorte. Eine Umgebung, in der jeder Standort nur den aktiv genutzten Arbeitsdatenbestand lokal bereitstellt, während die vollständige Datenbasis auf einer gemeinsamen Objektschicht liegt, skaliert im Wesentlichen mit dem tatsächlichen Zugriffsverhalten. Bei zwei- oder dreistelliger Standortzahl ist das der dominierende Kostenfaktor – und der Effekt wächst mit jeder Preissteigerung bei Primärmedien.
Damit gilt das Prinzip dieses Artikels auch auf einer zweiten Ebene: Nicht nur der Zugriffspfad, sondern auch die geografische Verteilung lässt sich von der Datenhaltung trennen. Die Zielarchitektur ist in beiden Fällen dieselbe – eine persistente Datenbasis mit differenzierten Zugriffsschichten darüber. Ob sie als Produkt eines Anbieters oder als zusammengesetzte Architektur realisiert wird, ist eine Frage von Beschaffungsrisiko, Abhängigkeit und Verteilungsanforderung, nicht des Architekturprinzips.
Zur Vollständigkeit gehört, wo zusammengesetzte Architekturen heute nicht mithalten. Zwei Fähigkeiten, die beide Analystenhäuser prominent bewerten, liegen dort typischerweise nicht in der Speicherschicht selbst: die aktive Erkennung von Verschlüsselungsanomalien im I/O-Pfad und die In-Place-Vektorisierung für AI-Pipelines. Beides lässt sich über benachbarte Komponenten abbilden, ist dann aber keine Eigenschaft der Objektplattform. Wer diese Funktionen ausdrücklich in der Storage-Ebene verankert haben möchte, trifft eine andere Architekturentscheidung – und sollte sie bewusst treffen.
Drei Fragen, die vor der Produktauswahl zu klären sind
Für eine Enterprise-Architektur lassen sich aus dieser Entwicklung drei Fragen ableiten, die einer Produktentscheidung sinnvollerweise vorausgehen.
Die erste betrifft den Umfang: Welche Daten sollen dauerhaft unabhängig von einzelnen Anwendungen existieren? Genau diese Daten sind Kandidaten für eine zentrale Datenplattform – nicht zwangsläufig alle anderen. In der Praxis ist diese Abgrenzung häufig der schwierigste Teil, weil sie eine Aussage über die erwartete Lebensdauer von Datenbeständen verlangt, die in vielen Organisationen nie getroffen wurde.
Die zweite betrifft die Zugriffspfade: Welche Verarbeitungsschritte können direkt über S3 erfolgen, und welche benötigen einen anderen Performancepfad? Diese Trennung verhindert, dass aus der grundsätzlichen KI-Eignung moderner Object-Systeme eine Universalitätsannahme wird, die spätestens in der ersten Trainingsschleife scheitert.
Die dritte betrifft die Bindung: Welche Datenservices dürfen an die Storage-Plattform gebunden werden? Tabellen, Vektoren, Events, Metadatendienste und KI-Funktionen reduzieren Architekturkomplexität, schränken die Portabilität aber stärker ein als das S3-Protokoll selbst. Diese Entscheidung sollte bewusst getroffen und dokumentiert werden, statt sich über einzelne Projekte hinweg unbemerkt zu ergeben.
Fazit
Die verbreitete Aussage, Object Storage werde vom Secondary zum Primary Storage, greift zu kurz, weil sie suggeriert, klassische File- oder Block-Systeme müssten ersetzt werden. Das ist nicht die entscheidende Entwicklung. Wichtiger ist, dass Object Storage zur primären Heimat der Daten werden kann, ohne für jeden Zugriff der primäre I/O-Pfad zu sein.
Ein GPU-Cluster kann weiterhin einen spezialisierten Performance Layer benötigen. Eine Datenbank wird weiterhin Block Storage verwenden. Anwender arbeiten möglicherweise über SMB oder ein Global File System. Trotzdem können die langfristig relevanten Unternehmensdaten darunter auf einer gemeinsamen Object-basierten Datenbasis liegen. Damit verschiebt sich die Bedeutung des Wortes „Primary" – weg vom schnellsten Speicher unmittelbar unter der Anwendung, hin zur maßgeblichen, dauerhaften und geschützten Datenbasis des Unternehmens.
An dieser Stelle treffen die bislang getrennt verlaufenden Entwicklungen Data Lake, Cloud-native Computing, Cyber Resilience und AI Infrastructure aufeinander. Daraus folgt die eigentlichstrategische Entscheidung: Unternehmen sollten Object Storage nicht danach bewerten, welche bisherigen Systeme sich damit ersetzen lassen, sondern danach, welche Rolle die Plattform künftig im gesamten Data Lifecycle übernehmen soll. Wer diese Entscheidung früh trifft, kann Compute, Analytics und KI wesentlich unabhängiger weiterentwickeln. Wer sie vertagt, riskiert, dass die nächste Generation von KI-Anwendungen lediglich eine weitere Schicht aus Datenduplikaten und Speicherinseln erzeugt.
Hinweis zu möglichen Interessenkonflikten: ASSISTRA implementiert und betreibt Storage-Infrastrukturen auf Basis von Produkten mehrerer der in diesem Artikel genannten oder bewerteten Anbieter. Die Einordnungen stützen sich auf die genannten Quellen und auf eigene Projekterfahrung; sie sind keine Produktempfehlung.
Quellen
Hinweis: Die drei Analystenberichte unterliegen Nutzungs- und Zitatbeschränkungen der jeweiligen Häuser. Dieser Artikel gibt keine Passagen im Wortlaut wieder, sondern fasst die beschriebene Marktrichtung zusammen. Anbieterplatzierungen sind zusätzlich in der unten genannten Fachberichterstattung dokumentiert und werden hier nicht als Bewertungs- oder Auswahlempfehlung verwendet.
Forrester Research – Brent Ellis et al. The Forrester Wave™: Object Storage Solutions, Q2 2026. Forrester Research, 2026. Für die Bewertung wurden Herstellerinformationen bis 2. April 2026 berücksichtigt. Öffentlich zugänglich als autorisierter Reprint unter reprint.forrester.com, abgerufen am 31. August 2026.
Gartner – Jeff Vogel, Joseph Unsworth et al. Magic Quadrant for Enterprise Storage Platforms. Gartner, ID G00841627, 19. August 2026. Öffentlich zugänglich als autorisierter Reprint über Everpure und HPE, abgerufen am 31. August 2026; die Freigabe ist befristet.
Whit Walters / GigaOm Radar for Object Storage v7 – From Archive to AI Factory: How Object Storage Became the Foundation of Modern Infrastructure. GigaOm, 2026. Der Report wird von Hitachi Vantara zum Download angeboten; Hitachi Vantara wird darin als Leader geführt.
Chris Mellor / Blocks & Files GigaOm object radar has 26 platform players vs Seagate. 30. Juni 2026.
Chris Mellor / Blocks & Files Gartner weaves enterprise storage magic spells – again. 24. August 2026.
Chris Mellor / Blocks & Files Forrester's object storage wave leaves out Cloudian, MinIO and many others. 24. August 2026.
Karl Fröhlich / speicherguide.de Gartner MQ26: Storage-Budgets 2027 könnten sich verdreifachen. 25. August 2026.
Uli Neiss / speicherguide.de Forrester und Gigaom: Object-Storage wird zur KI-Plattform. 26. August 2026.
Amazon Web Services Tables in S3 table buckets. Amazon S3 User Guide, abgerufen am 30. August 2026.
Amazon Web Services Amazon S3 Vectors is now generally available with 40 times the scale of preview. 2. Dezember 2025.
Amazon Web Services Amazon S3 Vectors expands to 17 additional AWS Regions. 31. März 2026.
NVIDIA Magnum IO GPUDirect Storage Overview Guide. Abgerufen am 30. August 2026.
Kubernetes SIG Storage Container Object Storage Interface (COSI). Projektdokumentation und Repository-Stand v1alpha2, abgerufen am 30. August 2026.
Kubernetes Introducing COSI: Object Storage Management using Kubernetes APIs. 2. September 2022.
IBM S3 over RDMA overview and deployment. IBM Storage Scale 6.0.1 Dokumentation, abgerufen am 30. August 2026.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
