In der Geodatenwelt ist «Cloud-Native» zum Buzzword geworden. Auf Konferenzen, in Produktbroschüren und in LinkedIn-Posts klingt es, als sei die Zukunft der Geoinformation bereits entschieden: Alles wird cloud-native, alles wird serverless, alles wird besser. Zeit, genauer hinzuschauen. Dieser Blogpost soll eine ehrliche Einordnung liefern. Was steckt hinter dem Begriff? Wo liegen die echten Stärken? Wo die Grenzen? Und wann fährt man mit klassischen Ansätzen schlicht besser?

Auch wir haben natürlich schon cloud-native Technologien eingesetzt und setzen sie auch weiterhin ein – sogar inklusive eigener Kategorie in diesem Blog! Aber unsere Erfahrungen haben gezeigt, dass man «cloud-native» differenzierter betrachten muss. Gerade weil wir uns intensiv damit auseinandergesetzt haben, wissen wir: Cloud-native geospatial ist kein Allheilmittel. Es ist ein Werkzeug – und wie bei jedem Werkzeug kommt es darauf an, ob man es am richtigen Ort einsetzt.

Was «Cloud-Native» bei Geodaten bedeutet

A cloud-native dataset is one with small addressable chunks via files, internal tiles, or both.

Cloud-Native Geospatial Forum

Cloud-Native Geospatial meint nicht einfach «Geodaten, die in der Cloud liegen». Ein Shapefile auf S3 abzulegen macht es nicht cloud-native – genauso wenig wie ein PDF auf Google Drive ein kollaboratives Dokument wird. Der entscheidende Punkt liegt in der internen Struktur der Daten: Cloud-native Formate sind so aufgebaut, dass Clients über einfache HTTP-Requests gezielt nur die Teile eines Datensatzes laden können, die sie tatsächlich brauchen: Statt ein 20GB-GeoTIFF komplett herunterzuladen, um einen kleinen Kartenausschnitt anzuzeigen, wird nur genau dieser Ausschnitt über einen HTTP Range Request geladen.¹

Damit das funktioniert, brauchen cloud-native Formate drei Eigenschaften:

• Die Daten sind intern in kleine, adressierbare Blöcke aufgeteilt (Tiles, Chunks, Row Groups).
• Die Metadaten – das «Inhaltsverzeichnis» zu den Daten – stehen an einer klar definierten Stelle (z.B. am Ende des Files bei Parquet), sodass ein Client mit einem einzigen Request herausfinden kann, wo die gewünschten Daten innerhalb der Datei liegen.
• Und die Formate müssen über HTTP-Requests angesprochen werden können – sei dies über einen Object Storage wie S3 oder über einen klassichen Fileserver.

Die wichtigsten Formate kurz erklärt

Für verschiedene Datentypen haben sich unterschiedliche Formate etabliert, mit denen unterschiedliche Fragestellungen umgesetzt werden können. Die Darstellungen entstammen verschiedenen «cloud-native»-Demonstratoren, die ich bei EBP umgesetzt habe.

Cloud-Optimized GeoTIFF

Cloud-Optimized GeoTIFF (COG) ist der De-facto-Standard für Rasterdaten. Im Kern handelt es sich um ein normales GeoTIFF, das aber intern gekachelt und mit Overviews (Pyramiden) versehen ist, sodass für verschiedene Zoomstufen nicht das gesamte Bild in seiner ganzen Detailtiefe geladen werden muss.

FlatGeoBuf

FlatGeobuf eignet sich für Vektordaten, wenn man räumlich filtern will: «Gib mir alle Gebäude in diesem Kartenausschnitt.» Ein integrierter Spatial Index macht das effizient, auch bei grossen Datensätzen.

GeoParquet

GeoParquet baut auf Apache Parquet auf und spielt seine Stärken bei analytischen Abfragen aus – etwa wenn man über Millionen von Objekten Attribute filtern oder aggregieren will. GeoParquet ist das Format, das Geodaten am besten an den modernen Data Stack bzw. Modern Data Stack (mit zum Beispiel DuckDB, Spark, Pandas) anschlussfähig macht (hierzu hat mein Kollege Stefan auch mal gebloggt).

PMTiles

PMTiles packt vorberechnete Kartenkacheln in eine einzige Datei mit internem Index – eine moderne Version der altgedienten WMTS-Server, und dank Vektorisierung auch nutzbar mit modernen Karten-Frameworks. Wir haben schon verschiedentlich in unserem Blog über PMTiles berichtet, etwa hier und hier.

Wo Cloud-Native wirklich glänzt

Wenn man die richtigen Rahmenbedingungen hat, sind die Vorteile von cloud-native real und substanziell:

• Distribution grosser Datensätze ohne Serverinfrastruktur: Wer heute einen grossen Datensatz publizieren will – ein Höhenmodell, ein Orthofoto-Mosaik, einen flächendeckenden Gebäudedatensatz – braucht im klassischen Modell einen WMS, einen WFS, einen Tile-Server, eine Datenbank, oder andere Komponenten. Mit cloud-nativen Formaten fällt ein Grossteil dieser Infrastruktur weg, da ein einfacher Fileserver genügt (oder, um richtig cloud-native zu sein, ein Object Storage wie S3). Das reduziert nicht nur Initialkosten, sondern auch den laufenden Betriebsaufwand.
• Webvisualisierung ohne Backend: COGs, FlatGeobufs, PMTiles und GeoParquets werden direkt im Browser geladen – ohne eigenes Backend. Die JavaScript-Clients sprechen direkt mit dem Object Storage. Für Webapplikationen, die Geodaten darstellen, ohne komplexe serverseitige Logik zu benötigen, ist das ein enormer Gewinn an Einfachheit.
• Anschlussfähigkeit an den Data-Engineering-Stack bzw. den Modern Data Stack: GeoParquets und COGs lassen sich in Workflows einbinden, die Data Engineers und Data Scientists ohnehin kennen. Geodaten rücken damit aus der GIS-Nische in die breitere Datenwelt (beispielsweise mit everybody’s darling DuckDB, über das etwa Ralph hier gebloggt hat).
• Selektiver Datenzugriff bei sehr grossen Datensätzen: Wer regelmässig mit sehr grossen Datensätzen arbeitet – Satellitenbilder, Klimadaten, nationale Vermessungsdaten – profitiert massiv davon, nur die benötigten Ausschnitte laden zu müssen, statt ganze Dateien herunterzuladen.

Und jetzt die ehrliche Einordnung: Die Stolperfallen

Genauso wichtig wie die Stärken sind die Grenzen. In der aktuellen Diskussion kommen diese oft zu kurz.

• «In der Cloud» ist nicht «cloud-native»: Das ist das häufigste Missverständnis, dem wir begegnen. Eine GeoPackage-Datei auf S3 abzulegen bringt wenig, wenn man sie trotzdem komplett herunterladen muss. Die Konvertierung bestehender Daten in cloud-native Formate ist ein eigener, nicht-trivialer Schritt mit eigenen Entscheidungen (Tiling-Schema, Kompression, Sortierung) und eigenem Automatisierungsbedarf.
• HTTP-Latenz summiert sich: Cloud-native Formate optimieren die Menge der übertragenen Daten, aber jeder HTTP-Request hat eine gewisse Grundlatenz. Bei Szenarien mit vielen kleinen, sequenziellen Requests kann sich das spürbar summieren. Besonders wenn Client und Daten nicht in derselben Cloud-Region liegen, ist eine lokale Datenbank oder ein spezialisierter Service schneller.
• Schreiben ist nicht Lesen: Cloud-native Formate sind auf effizientes Lesen optimiert. Sie eignen sich als Distributionsformat, nicht als Arbeitsformat für häufige Schreiboperationen. Es gibt kein Update-in-Place, keine Transaktionen, keine Row-Level-Deletes. Wer das braucht, muss auf zusätzliche Schichten wie Apache Iceberg oder Delta Lake zurückgreifen.
• Tooling-Reife ist ungleich verteilt: Das Python-Ökosystem (mit zum Beispiel rasterio, fsspec, xarray, dask) ist ausgereift. In anderen Umgebungen – R, JavaScript, klassische Desktop-GIS-Anwendungen – stösst man heute noch auf Lücken.
• Es gibt kein Universalformat: FlatGeobuf ist stark bei räumlichen Abfragen, aber schwach bei analytischen Spaltenabfragen. GeoParquet glänzt bei thematischen Analysen, hat aber keinen eingebauten Spatial Index für schnelle Bounding-Box-Abfragen auf Geometrien. Die falsche Formatwahl führt zu schlechterer Performance als der klassische Ansatz.
• Zugriffsschutz: Auch wenn WMS und Konsorten nicht per se zugriffsgeschützt sind, haben wir mittlerweile eine Vielzahl von Möglichkeiten, um mehr oder weniger komplexe Zugriffsmechanismen einzurichten. Cloud-native Formate stellen wiederum eigene Herausforderungen dar, denn sobald ein File in einen öffentlichen S3-Bucket gelegt wird, ist es «da draussen» und kann kopiert werden.
• Neue Herausforderungen und Optimierungen: Mittlerweile kennen wir viele Tricks und Kniffe, um das Maximum aus unseren PostGIS-Instanzen herauszuoptimieren – vom einfachen vergessenen Index bis hin zu komplexen SQL-Tricks um den QueryPlanner zu überlisten. Neue Formate bedeuten komplett neue Herausforderungen, denn ein simples SELECT * FROM my_table kann mit DuckDB plötzlich ganz schön ineffizient (und teuer) sein, weil Optimierungen so nicht greifen (dieser Blogpost zeigt einige Pitfalls).

Brauche ich das überhaupt?

Das ist die Frage, die zu selten gestellt wird. Und die ehrliche Antwort lautet oft: nein.

Wer mit Datensätzen arbeitet, die auf eine lokale Festplatte passen, und wer seine Analysen auf dem eigenen Rechner oder einem einzelnen Server fährt, braucht nicht zwingend cloud-native Formate. Ein GeoPackage, ein normales GeoTIFF, eine PostGIS-Datenbank – diese Werkzeuge funktionieren seit Jahren zuverlässig und sind für viele Anwendungsfälle nach wie vor die richtige Wahl. Nicht alles, was man auf einer Konferenz (oder LinkedIn…) als veraltet erklärt bekommt, ist tatsächlich überholt. Wer einen überschaubaren Datensatz in QGIS laden und analysieren will, fährt mit einem GeoPackage otfmals immer noch besser als mit einer GeoParquet-Datei auf S3. Und das ist völlig in Ordnung.

Auch die vermeintliche Einfachheit – «kein Server mehr nötig!» – hat ihre Kehrseite. Object Storage will verwaltet werden, Zugriffsrechte müssen konfiguriert werden, Konvertierung-Pipelines müssen gebaut und gepflegt werden. Man tauscht eine Art von Komplexität gegen eine andere. Ob das ein Gewinn ist, muss im konkreten Kontext entschieden werden.

Ganz kurz und vereinfachend gesagt: Cloud-Native Geospatial entfaltet seinen Mehrwert vor allem dort, wo mindestens einer der folgenden Faktoren zutrifft:

• Die Daten sind zu gross, um sie sinnvoll herunterzuladen.
• Die Daten sollen einer breiten Öffentlichkeit ohne aufwändige Serverinfrastruktur zugänglich gemacht werden.
• Die Daten sind relativ stabil und ändern sich selten oder am besten gar nicht (z.B. Luftbild-Daten).
• Die Daten sollen in Workflows eingebunden werden, die ausserhalb der klassischen GIS-Welt leben oder dazu anschlussfähig sein müssen – in Data Pipelines, in Webanwendungen, in analytischen Plattformen.

Unser Fazit

Auch wenn wir bei EBP gerne neue Technologien ausprobieren und natürlich auch manchmal nach einer Konferenz (z.B. FOSS4G 2023) der «conference-driven architecture»² erliegen, ist eine kritische Einordnung vielversprechender Technologien wichtig, um diese möglichst gewinnbringend zu nutzen.

Unsere Empfehlung: Nicht fragen «Wie machen wir unsere Daten cloud-native?», sondern «Welches Problem wollen wir lösen? Und ist ein cloud-natives Format dafür die beste Antwort?» Manchmal lautet die Antwort «ja». Manchmal lautet sie: «PostGIS reicht». Beides sind gute Antworten, wenn sie auf einer fundierten Beurteilung beruhen.

Die Geodatenwelt wird sich in den nächsten Jahren weiter verändern, und cloud-native Formate werden dabei eine wichtige Rolle spielen. Aber die beste Technologieentscheidung ist immer noch die, die man aus tiefem Verständnis trifft.

In einem unserer nächsten Blogposts werden wir ein Projekt vorstellen, das wir mit cloud-native Technologien umgesetzt haben – inklusive Vor- und Nachteilen sowie lessons learned. Falls Sie unterdessen Fragen haben, kontaktieren Sie uns gerne per Mail!

1. Für eine vertiefte Einführung hat das Cloud-Native Geospatial Forum eine sehr umfassende Guide-Sammlung veröffentlicht und führt diese auch aktiv nach. ↩︎
2. Leider kein direktes Zitat, aber Dr. Gernot Starke hat diesen Begriff in einer ISAQB-Schulung genutzt und ich finde ihn so passend. ↩︎