Carsten betreibt seit zwei Jahren die Datenplattform eines mittelständischen Versicherers in Hannover. Im Frühjahr 2024 hatte das Team beschlossen, alle Rohdaten künftig in einem zentralen Bucket abzulegen. Die Wahl fiel auf MinIO, selbst betrieben auf drei Servern im hauseigenen Rechenzentrum. Carsten installierte das System, schrieb Onboarding-Dokumente und hielt zwei Workshops für die Entwicklerteams. Im Mai 2025 verschwand die Web-Konsole aus der Community-Edition. Im Oktober 2025 stellte das Projekt die offizielle Bereitstellung von Binärpaketen und Container-Images ein. Am 12. Februar 2026 wurde das Repository auf GitHub schließlich archiviert. Plötzlich saß sein Team auf einer Software, die offiziell nicht mehr gepflegt wurde, und musste innerhalb weniger Wochen einen Migrationspfad finden.

Carstens Geschichte ist nicht erfunden, sondern in Variationen aus mehreren deutschen Unternehmen bekannt. Die meisten Teams haben sich in den vergangenen Wochen für eine Umstellung auf SeaweedFS oder einen Wechsel zu Hetzner Object Storage entschieden. Die eigentliche Lehre aus diesen Migrationen ist jedoch nicht die Tool-Wahl, sondern das Bewusstsein, wie viel architektonische Stabilität in der untersten Schicht einer Datenplattform steckt. Wer beim Fundament wackelt, riskiert, dass Pipelines, Berichte und ML-Pipelines nachziehen müssen.

Diese Episode steht beispielhaft für eine Entwicklung, die in den letzten Monaten viele Datenteams beschäftigt hat. Object Storage ist seit Jahren das Fundament moderner Datenplattformen, doch die Werkzeuglandschaft drumherum ist in Bewegung. Wer heute neu beginnt, sollte verstehen, was Object Storage technisch ausmacht, warum sich die S3-API als faktischer Standard durchgesetzt hat und welche Anbieter und Open-Source-Projekte 2026 tatsächlich tragfähig sind. Dieser Teil beantwortet genau diese Fragen.

Was unterscheidet Object Storage von klassischen Speichern?

Object Storage verwaltet Daten nicht als Dateien in Verzeichnissen, sondern als unveränderliche Objekte in einem flachen Namensraum. Jedes Objekt besteht aus dem eigentlichen Inhalt, einer eindeutigen Schlüsselbezeichnung und beliebigen Metadaten. Diese Objekte liegen in Behältern, die Buckets heißen. Was wie ein Verzeichnispfad aussieht, ist tatsächlich nur Teil des Schlüssels, der durch Schrägstriche strukturiert wird. Der Unterschied klingt akademisch, hat aber gravierende Konsequenzen für die Skalierbarkeit. Klassische Dateisysteme müssen Verzeichnisbäume durchlaufen, um eine Datei zu finden. Object Storage adressiert Milliarden von Objekten ohne diesen Umweg.

Der Zugriff erfolgt über HTTP gegen eine REST-Schnittstelle, nicht über Betriebssystem-APIs. Jede Operation ist in sich abgeschlossen, was bedeutet, dass Lese- und Schreibvorgänge sich nahezu beliebig parallelisieren lassen. Hunderte Worker können gleichzeitig denselben Bucket adressieren, ohne dass eine zentrale Sperrungs- oder Inode-Schicht zum Engpass wird. Genau diese Eigenschaft macht Object Storage so attraktiv für analytische Workloads, bei denen viele verteilte Prozesse parallel auf große Datenbestände zugreifen.

Drei große Speicherparadigmen existieren parallel und erfüllen jeweils unterschiedliche Aufgaben.

EigenschaftBlockspeicherDateispeicherObject Storage
AdressierungLogische BlocknummernPfad und DateinameBucket und Schlüssel
SchnittstelleiSCSI, NVMe, SASNFS, SMB, CIFSHTTP, S3-API
GranularitätBlockweiseDatei, byteweiseKomplettes Objekt
SkalierungBegrenzt durch VolumeBegrenzt durch ServerPraktisch unbegrenzt
Typischer EinsatzDatenbanken, BetriebssystemeKlassische FileserverBackups, Medien, Data Lakes
MetadatenSehr armKlassisches DateisystemFrei erweiterbar pro Objekt

Für Datenplattformen ist die letzte Spalte entscheidend. Object Storage ist die richtige Wahl, wenn Daten einmal geschrieben und vielfach gelesen werden, wenn das Volumen unvorhersehbar wächst und wenn unterschiedliche Verarbeitungssysteme auf denselben Bestand zugreifen sollen.

Wie der S3-Standard zum Default wurde

Amazon eröffnete 2006 mit Simple Storage Service den Markt für Cloud-Object-Storage. Die zugehörige API hat sich seitdem zum De-facto-Standard entwickelt. Wenn von einem S3-kompatiblen Produkt die Rede ist, bedeutet das schlicht, dass es dieselben HTTP-Endpunkte und Signaturalgorithmen versteht wie das Original aus Seattle. Anwendungen, die mit Amazons Dienst arbeiten, können denselben Code gegen ein alternatives System nutzen. Lediglich Endpunkt-URL und Zugangsdaten ändern sich.

Diese Standardisierung ist eine seltene Wohltat im Cloud-Geschäft. Sie hat den Markt offen gehalten und Anwendern eine Verhandlungsposition gegeben, die in geschlossenen Datenarchitekturen nur schwer zu erlangen ist. Werkzeuge wie Spark, Polars oder DuckDB sprechen alle dieselbe Sprache und können beliebige Backends adressieren. Wer eine Plattform aufbaut, sollte diese Eigenschaft als verlässliches Versprechen einpreisen. Der Wechsel von einem Cloud-Anbieter zum nächsten ist kein Sechs-Monate-Projekt, sondern eine geplante Migration über Wochen.

Es lohnt sich, einen Moment darüber nachzudenken, warum das so ist. S3-Kompatibilität funktioniert, weil die Schnittstelle vergleichsweise schmal und gut dokumentiert ist. Es gibt keine proprietären Treiber, keine versteckten Performance-Eigenheiten und keine Lizenzfragen, die einer Reimplementierung im Weg stehen. Genau diese Sparsamkeit ist der Grund, warum sich heute selbst kleine Open-Source-Projekte erlauben können, die API vollständig nachzubilden. Der Markt belohnt diese Offenheit, indem er Anbieter unabhängig von ihrer Größe auf Augenhöhe behandelt.

Welche Hyperscaler-Angebote lohnen sich für DACH-Workloads?

Wer keinen eigenen Speicher betreiben möchte, wählt zwischen einer ganzen Reihe von Managed Services. Sie unterscheiden sich vor allem in Preisstruktur, regionaler Verfügbarkeit, Sicherheitsfunktionen und in den Egress-Gebühren beim Verlassen der Plattform. Die folgende Übersicht zeigt das Feld zum Stand April 2026.

AnbieterStorage pro GBEgressBemerkung
AWS S3ab 0,023 USDab 0,09 USD/GB (gestaffelt, erste 100 GB frei)Maßstab und Ökosystem-Standard [11]
Azure Blob Storageab 0,018 USD0,087 USD/GB (erste 10 TB)S3-Kompatibilität nur über Drittdienste [12]
GCP Cloud Storageab 0,020 USD0,12 USD/GB (1. TB), dann gestaffeltEigene API plus S3-kompatibler Endpunkt
Cloudflare R20,015 USD0,00 USD/GBClass A: 4,50 USD/Mio. Writes, Class B: 0,36 USD/Mio. Reads [1]
Backblaze B20,006 USD0,01 USD/GB ab 3x Storage, darunter freiÜber Bandwidth Alliance kostenfrei zu Cloudflare [2]
Wasabi0,0068 USD0,00 USD bis Storage-Volumen, max. 100 TB/Monat1 TB Mindestvertrag, 90-Tage-Mindestlagerung [3]
Hetzner Object Storage6,49 EUR/Monat (1 TB, vorher 4,99 EUR)0,00 EUR innerhalb EUFalkenstein, Helsinki, Nürnberg [4]
IONOS Object Storage0,015 EUR0,06 EUR/GBDSGVO-konform, deutsche Rechenzentren [14]

Hetzner verdient eine eigene Erwähnung. Der deutsche Anbieter rollt sein Object Storage seit 2024 produktiv aus und hat die Preise zum 1. April 2026 deutlich angehoben (von 4,99 EUR auf 6,49 EUR pro Monat im Standardpaket inklusive 1 TB Speicher und 1 TB Egress, das sind etwa 30 Prozent Aufschlag). Begründet wurde der Sprung mit gestiegenen Hardware-Kosten, vor allem für DRAM. Innerhalb der EU-Zone fallen für Egress weiterhin keine Gebühren an, was Plattformen mit deutschen oder europäischen Nutzern erheblich entlastet. IONOS bietet eine direkte Alternative mit reinem Pay-as-you-go-Modell (0,015 EUR pro GB Storage und 0,06 EUR pro GB Outbound), ebenfalls in deutschen Rechenzentren und DSGVO-konform. Für Workloads mit DSGVO-Anforderungen oder Sovereign-Cloud-Vorgaben sind diese Optionen oft die einfachere Antwort als der Versuch, Hyperscaler über vertragliche Klauseln einzuhegen.

Die rechtliche Komponente verdient eine kurze Vertiefung. Der CLOUD Act von 2018 verpflichtet US-Anbieter, US-Behörden auf Anfrage Zugriff auf Kundendaten zu gewähren, unabhängig vom Speicherort. Die Diskussion über die DSGVO-Konformität dieser Konstellation hat Datenschutzbeauftragte in vielen Konzernen beschäftigt, und die Antworten der Anbieter (regional begrenzte Verschlüsselung, Bring-Your-Own-Key-Verfahren) wirken auf manche Aufsichtsbehörde eher wie Beruhigungsmittel als wie eine Lösung. Wer in einer regulierten Branche arbeitet (Bank, Versicherung, Krankenhaus, öffentliche Verwaltung), sollte zumindest prüfen, ob ein europäischer Anbieter operativ machbar wäre. GAIA-X als europäische Cloud-Initiative hat zwar bisher weniger ausgeliefert als angekündigt, aber die zugrundeliegenden Standards für Datensouveränität fließen zunehmend in die Vergabeverfahren der öffentlichen Hand ein.

Cloudflare R2 hat sich in den letzten zwei Jahren zur Standardwahl für Workloads entwickelt, bei denen Daten häufiger gelesen als geschrieben werden. Wer ein öffentliches Mediaarchiv, einen Backup-Pool für viele kleine Kunden oder die Auslieferungsschicht eines KI-Systems baut, sollte R2 ernsthaft prüfen. Die Egress-freie Politik verändert die Wirtschaftlichkeitsrechnung dramatisch. Wichtig zu wissen: R2 berechnet zwar keinen Egress, dafür aber Operations getrennt mit 4,50 USD pro Million Schreib-Vorgänge (Class A) und 0,36 USD pro Million Leseoperationen (Class B). Für lese-lastige Workloads bleibt das insgesamt sehr günstig. Backblaze B2 ist für reine Backup-Szenarien das günstigste etablierte Angebot, zumal Egress unter der dreifachen Storage-Menge pro Monat ganz entfällt. Erst über dieser Schwelle werden 0,01 USD pro GB fällig. In Kombination mit der Bandwidth Alliance ist der Datentransfer zu Cloudflare ohnehin vollständig kostenfrei.

Ein konkretes Beispiel aus dem Mittelstand zeigt das Muster. Ein Hamburger E-Commerce-Anbieter wechselte 2024 die Speicherung von Produktbildern und Videos von AWS S3 zu Cloudflare R2. Die Auslieferung erfolgte ohnehin über Cloudflare als CDN. Vor der Umstellung lagen die monatlichen Kosten bei rund 8.400 EUR, davon entfielen mehr als 70 Prozent auf Egress-Gebühren. Nach der Migration sanken die Gesamtkosten auf rund 1.200 EUR, ohne dass an der Architektur sonst etwas verändert wurde. Die Migration selbst dauerte zwei Wochen, weil dieselben SDKs und Tools weitergenutzt wurden. Solche Größenordnungen sind kein Einzelfall, sondern eine direkte Folge der Egress-Lastigkeit klassischer Cloud-Preismodelle.

Eine ehrliche Wertung gehört dazu. AWS S3 bleibt für viele Großunternehmen die Default-Wahl, obwohl es bei reinen Speicherkosten die teuerste Option ist. Der Grund liegt im Ökosystem. Wer ohnehin Lambda, Athena oder SageMaker einsetzt, profitiert von der nahtlosen Anbindung. Wer einen reinen Datenbestand verwalten will und keine Bindung an Amazons Tools hat, lässt 30 bis 70 Prozent Kosten liegen, indem er bei AWS bleibt. Die Wahl zwischen Hyperscaler und EU-Anbieter ist deshalb selten eine reine Preisfrage. Sie hängt davon ab, wie tief die übrige Architektur bereits in einem Anbieter-Universum verankert ist und welche organisatorischen Hürden eine Migration überhaupt zulassen würde.

Was kommt nach dem Aus von MinIO?

Die Eingangsgeschichte aus Hannover steht für eine reale Entwicklung. MinIO galt jahrelang als das Standard-Werkzeug für selbst betriebenen S3-kompatiblen Speicher. Im Mai 2025 entfernte das Projekt die Web-Konsole aus der Community-Edition, was für viele Betreiber bereits ein Alarmsignal war. Im Oktober 2025 wurden auch die offiziellen Binärpakete und Container-Images eingestellt. Im Dezember 2025 wechselte das Repository in den Maintenance Mode, und am 12. Februar 2026 archivierte der Eigentümer den Code endgültig [5][6]. Wer heute nach MinIO sucht, findet ein eingefrorenes Repository mit dem Hinweis "no longer maintained". Die Botschaft ist eindeutig: Das Unternehmen lenkt seine Kundschaft in das kommerzielle AIStor-Produkt, das mit Lizenzkosten ab rund 100.000 USD pro Jahr für 400 TiB für viele Mittelständler unerschwinglich ist. Eine Community-Initiative hat unterdessen einen Fork (pgsty/minio) aufgesetzt, der die Admin-Konsole zurückbringt und Binaries via CI/CD-Pipeline weiterhin verteilt. Wer eine bestehende MinIO-Installation kurzfristig stabilisieren will, hat mit diesem Fork einen funktionierenden Pfad.

Die Open-Source-Landschaft hat darauf in mehreren Ausprägungen reagiert. Drei Projekte sind im Frühjahr 2026 besonders relevant.

ProjektStand April 2026StärkenEmpfehlung
SeaweedFSAktiv gepflegt, Go, Apache 2.0, eigenes S3-Gateway, Iceberg-Tabellen-SupportSehr gut bei vielen kleinen Objekten, gemischte WorkloadsAllgemeiner Einstieg, auch für Container-Plattformen [7]
GarageAGPLv3, Rust, Deuxfleurs (FR), seit 2020 produktivGeo-verteilte kleine bis mittlere Cluster, toleriert 200 ms Netzwerk-Latenz, single binaryEdge- und Multi-Standort-Setups [8]
RustFSApache 2.0, Rust, Beta angekündigt für April 2026, GA für Juli 2026Hohe Performance bei kleinen Objekten (Faktor 2,3 schneller als MinIO bei 4 KB), MinIO-Migration eingebautSingle-Node heute, Mehrknoten ab GA [9]
Ceph mit RGWEtabliert, sehr breites Funktionsspektrum, Squid 19.2 und Tentacle 20.x aktuellPetabyte-Cluster, OpenStack/Rook-IntegrationGroße Eigenbetriebe mit Plattformteam

SeaweedFS hat in den letzten Monaten an Boden gewonnen, weil das Kubeflow-Projekt mit der Version Kubeflow 1.11 (KFP 2.15) MinIO als Standard-Backend offiziell durch SeaweedFS ersetzt hat. Begründung der Maintainer: Die AGPLv3-Lizenz von MinIO blockierte Upgrades und Security-Patches in Multi-Tenant-Umgebungen. Wer also Daten- und ML-Pipelines auf Kubernetes betreibt, läuft sowieso in dieses Werkzeug hinein. Garage ist mein persönlicher Favorit für kleine, geografisch verteilte Setups, etwa wenn ein Verein, eine Genossenschaft oder ein kleines Unternehmen mit zwei Standorten arbeitet. Der Funktionsumfang ist bewusst schmal (kein Object Locking, keine Versionierung, keine Lifecycle-Regeln), aber für viele reale Szenarien reicht das vollkommen. Deuxfleurs selbst betreibt Garage seit 2020 produktiv, was als Stabilitätsnachweis durchgeht.

RustFS ist die spannendste, aber auch riskanteste Option. Das Projekt positioniert sich offen als geistiger Nachfolger von MinIO und liefert Migrations-Werkzeuge, mit denen sich bestehende MinIO-Daten ohne Umweg übernehmen lassen. Anfang 2026 läuft RustFS produktiv noch im Single-Node-Modus, die offizielle Beta-Phase mit verteiltem Cluster-Modus ist für April 2026 angekündigt, die General Availability für Juli 2026. Für reine Single-Node-Workloads ist das tragbar, für produktive Mehrknoten-Cluster sollte man bis zur GA warten. Im April 2026 ist das Projekt zudem in das NVIDIA-Inception-Programm aufgenommen worden, was die Sichtbarkeit zusätzlich erhöht. Ceph schließlich ist die Schwergewichts-Option. Wer bereits OpenStack oder Rook betreibt und ein Plattformteam mit zehn oder mehr Personen hat, wird die operative Komplexität schultern können. Für alle anderen ist Ceph ein Werkzeug, das man eher meiden sollte.

Eine Frage, die in jeder dieser Diskussionen aufkommt, lautet, ob sich der Eigenbetrieb überhaupt noch lohnt. Meine ehrliche Einschätzung: Bei Datenmengen unter 50 Terabyte ist Hetzner Object Storage oder Backblaze B2 in fast allen Fällen die rationalere Wahl. Erst ab Petabyte-Volumen oder bei spezifischen Latenzanforderungen rechnet sich der Eigenbetrieb mit dem dazugehörigen Personalaufwand. Wer dennoch selbst betreiben will, hat mit SeaweedFS und Garage zwei stabile Optionen.

Carstens Versicherer aus der Eingangsgeschichte hat sich übrigens für SeaweedFS entschieden. Die Migration verlief in vier Schritten. Zuerst wurde ein zweiter Cluster parallel zum laufenden MinIO aufgesetzt. Dann liefen die produktiven Schreibvorgänge eine Zeit lang dual auf beide Systeme, was sich mit S3-kompatiblen Tools wie rclone trivial lösen ließ. In Schritt drei wurden die historischen Daten kopiert und auf Konsistenz geprüft. Schritt vier war der eigentliche Cutover: Die Anwendungs-Endpunkte wurden umgeschrieben, die alten MinIO-Buckets als read-only markiert und nach drei Wochen Stillstand archiviert. Insgesamt acht Wochen Aufwand, ohne Datenverlust und ohne nennenswerte Downtime für Endnutzer.

Welche Werkzeuge im Alltag wirklich helfen

Object Storage ist primär eine Schnittstelle für Anwendungen, nicht für Menschen. Im Alltag braucht es trotzdem eine Möglichkeit, Buckets zu inspizieren, einzelne Objekte herunterzuladen oder Berechtigungen zu kontrollieren. Filestash hat sich als populäre Open-Source-Lösung für diesen Zweck etabliert [10]. Es bindet S3-, SFTP-, WebDAV- und SMB-Backends gleichermaßen an und liefert eine Web-Oberfläche, die viele Datenteams an Dropbox erinnert. Multi-User-Verwaltung, Vorschauen für gängige Dateiformate, geteilte Links und Single-Sign-On-Anbindung sind eingebaut.

Daneben existieren Werkzeuge mit anderem Fokus. Cyberduck (aktuelle Version 9.4.1 vom 3. März 2026 [13]) und Mountain Duck sind klassische Desktop-Clients für macOS und Windows, die sich für Einzelnutzer eignen, etwa wenn ein Datenanalyst gelegentlich auf einen Bucket zugreifen muss. Mountain Duck 5 bringt einen Integrated Connect Mode, der Cloud-Speicher direkt im Finder oder Explorer einbindet, ohne dass ein Treiber installiert werden muss. AList und Nextcloud bieten eine ähnliche Oberfläche wie Filestash, decken aber auch Anwendungsfälle wie Kalender, Kontakte oder Office-Workflows mit ab. Wer einen reinen S3-Browser sucht, ohne ein zweites File-Sharing-System aufzubauen, ist mit Filestash am besten bedient. Ein Hinweis zur Sicherheit: Diese Werkzeuge sollten konsequent hinter einer Authentifizierungsschicht stehen, idealerweise mit einem zentralen Identity-Provider. Object Storage hat keine eingebauten Schutzmechanismen gegen versehentlich öffentlich gemachte Buckets, und ein Dashboard ohne Login ist eine Datenschutz-Katastrophe in Wartestellung.

Auf der Bucket-Ebene selbst gehört eine bewusste Policy zur Pflichtausstattung. Bei den Hyperscalern wirkt die Kombination aus IAM-Rollen, Bucket-Policies und Object Ownership zunächst überfordernd, ist aber das einzige verlässliche Mittel gegen die klassischen Pannen. Versehentlich offene Listings, Schreibrechte für anonyme Nutzer oder ein vergessenes Public-Bit haben in den vergangenen Jahren mehr Datenpannen verursacht als alle anderen Konfigurationsfehler zusammen. Bei selbst betriebenen Lösungen wie SeaweedFS oder Garage ist die Logik einfacher gestrickt, dafür liegt mehr Verantwortung beim Betreiber. Eine Mindestkontrolle besteht aus drei Bausteinen: Verschlüsselung im Ruhezustand, signierte URLs für externe Zugriffe und ein automatisches Audit, das mindestens wöchentlich nach öffentlich erreichbaren Objekten scannt.

Fazit und Ausblick

Drei Punkte halte ich nach allem, was 2026 bisher passiert ist, für wichtig. Erstens ist S3-Kompatibilität nicht verhandelbar. Wer beim Aufbau einer neuen Plattform überlegt, eine proprietäre Schnittstelle zu nutzen, sollte sich die Geschichte von MinIO als warnendes Beispiel vor Augen halten. Auch Open-Source-Projekte können verschwinden, aber die offene API garantiert, dass die Migration kein Totalausfall wird. Zweitens lohnt sich ein nüchterner Blick auf die eigenen Datenmengen. Selbstbetrieb klingt nach Kostenkontrolle, ist aber bei kleinen und mittleren Volumen meistens teurer als ein Managed Service in einem deutschen Rechenzentrum. Drittens schließt eine bewusste Wahl der Speicher-Schicht alle weiteren Architekturentscheidungen mit ein. Parquet, Iceberg, Spark, DuckDB und ClickHouse setzen alle auf einer S3-kompatiblen Grundlage auf. Ohne diese Schicht hängt der gesamte Stack in der Luft.

Im nächsten Teil geht es um die Frage, was eigentlich in diesen Buckets liegen sollte. Parquet, Iceberg und Delta Lake heben das nackte Object Storage auf eine echte Tabellenabstraktion und ermöglichen damit erst das, was heute als Data Lakehouse bezeichnet wird. Wer das Fundament aus Teil 1 sauber gewählt hat, baut darauf eine Schicht, die analytische Garantien liefert, ohne dass die Offenheit der unteren Schicht verloren geht. Genau diese Verschränkung beider Ebenen prägt den Stack, den moderne Plattformen 2026 zunehmend als Standard verwenden.

Eine letzte praktische Anmerkung gehört in diesen ersten Teil. Wer eine neue Plattform plant, sollte den ersten Bucket bewusst klein halten und schrittweise wachsen lassen. Eine einzelne Bronze-Bucket-Hierarchie reicht in den meisten Fällen für die ersten sechs Monate. Erst wenn klar wird, welche Datenquellen tatsächlich produktiv genutzt werden, lohnt sich der Aufbau weiterer Schichten und Berechtigungsmodelle. Diese organische Wachstumsstrategie schützt vor zwei häufigen Fehlern, der überdimensionierten Anfangsarchitektur und der unvollständigen Inventur dessen, was die Datenquellen wirklich liefern.

Quellen

[1] Cloudflare R2 Pricing Documentation, Stand April 2026 (https://developers.cloudflare.com/r2/pricing/)

[2] Backblaze B2 Cloud Storage Pricing, Stand April 2026 (https://www.backblaze.com/cloud-storage/pricing)

[3] Wasabi Pricing FAQ und Minimum Storage Duration Policy, Stand April 2026 (https://wasabi.com/pricing/faq, https://docs.wasabi.com/docs/how-does-wasabis-minimum-storage-duration-policy-work)

[4] Hetzner Object Storage Dokumentation und Statement zur Preisanpassung 1. April 2026 (https://docs.hetzner.com/storage/object-storage/overview/, https://www.hetzner.com/pressroom/statement-price-adjustment/)

[5] MinIO Is Dead, Long Live MinIO, vonng-Blog, Februar/März 2026 (https://blog.vonng.com/en/db/minio-resurrect/)

[6] MinIO Community Edition is Archived, The Cloud Support Engineer, Februar 2026 (https://thecloudsupportengineer.com/the-end-of-an-era-minio-community-edition-is-archived-whats-next/)

[7] Kubeflow Pipelines Embraces SeaweedFS (KFP 2.15 / Kubeflow 1.11.0), 2026 (https://medium.com/@hpotpose26/kubeflow-pipelines-embraces-seaweedfs-9a7e022d5571)

[8] Garage Object Storage Features und Dokumentation, Deuxfleurs, Stand April 2026 (https://garagehq.deuxfleurs.fr/documentation/reference-manual/features/)

[9] RustFS Roadmap und Releases, GitHub, Stand April 2026 (https://github.com/rustfs/rustfs/releases)

[10] Filestash Projektseite und Plugin-Dokumentation, Stand April 2026 (https://www.filestash.app/, https://www.filestash.app/docs/plugin/)

[11] AWS S3 Pricing, Stand April 2026 (https://aws.amazon.com/s3/pricing/)

[12] Azure Blob Storage Pricing, Microsoft, Stand April 2026 (https://azure.microsoft.com/en-us/pricing/details/storage/blobs/)

[13] Cyberduck Release Notes 9.4.1, März 2026 (https://version.cyberduck.io/changelog.html)

[14] IONOS Object Storage Pricing, Stand April 2026 (https://docs.ionos.com/cloud/storage-and-backup/ionos-object-storage/overview/pricing)

Quellen

[1] Cloudflare R2 Pricing Documentation, Stand April 2026 (https://developers.cloudflare.com/r2/pricing/)
[2] Backblaze B2 Cloud Storage Pricing, Stand April 2026 (https://www.backblaze.com/cloud-storage/pricing)
[3] Wasabi Pricing FAQ und Minimum Storage Duration Policy, Stand April 2026 (https://wasabi.com/pricing/faq, https://docs.wasabi.com/docs/how-does-wasabis-minimum-storage-duration-policy-work)
[4] Hetzner Object Storage Dokumentation und Statement zur Preisanpassung 1. April 2026 (https://docs.hetzner.com/storage/object-storage/overview/, https://www.hetzner.com/pressroom/statement-price-adjustment/)
[5] MinIO Is Dead, Long Live MinIO, vonng-Blog, Februar/März 2026 (https://blog.vonng.com/en/db/minio-resurrect/)
[6] MinIO Community Edition is Archived, The Cloud Support Engineer, Februar 2026 (https://thecloudsupportengineer.com/the-end-of-an-era-minio-community-edition-is-archived-whats-next/)
[7] Kubeflow Pipelines Embraces SeaweedFS (KFP 2.15 / Kubeflow 1.11.0), 2026 (https://medium.com/@hpotpose26/kubeflow-pipelines-embraces-seaweedfs-9a7e022d5571)
[8] Garage Object Storage Features und Dokumentation, Deuxfleurs, Stand April 2026 (https://garagehq.deuxfleurs.fr/documentation/reference-manual/features/)
[9] RustFS Roadmap und Releases, GitHub, Stand April 2026 (https://github.com/rustfs/rustfs/releases)
[10] Filestash Projektseite und Plugin-Dokumentation, Stand April 2026 (https://www.filestash.app/, https://www.filestash.app/docs/plugin/)
[11] AWS S3 Pricing, Stand April 2026 (https://aws.amazon.com/s3/pricing/)
[12] Azure Blob Storage Pricing, Microsoft, Stand April 2026 (https://azure.microsoft.com/en-us/pricing/details/storage/blobs/)
[13] Cyberduck Release Notes 9.4.1, März 2026 (https://version.cyberduck.io/changelog.html)