November 06, 2026 • 6 min read • Published by David G. Smith

Icebergs, Maps, and Where We Can Go With Spatial Data Lakes

Cloud-Native Geospatial Data Engineering Data Governance Open Source GIS Spatial SQL Geospatial

Lately, I've been having a lot of conversations with colleagues getting them up to speed on Apache Iceberg.

That's not particularly surprising. Iceberg has steadily moved from being a niche data engineering topic into something that architects, analytics teams, and platform engineers are discussing with increasing seriousness. What recently surprises me, though, is realizing how naturally Iceberg fits into a much larger transformation that's occurring in geospatial data.

A few weeks ago, I wrote about that transformation in "Portolan and the Quiet Reinvention of Spatial Data Infrastructure":

That article focused primarily on how cloud-native formats, object storage, and standards like STAC are quietly replacing layers of traditional GIS infrastructure. Revisiting the topic after reading more about Portolan and the emerging STAC Iceberg Extension currently being developed, I'm increasingly convinced that we're watching several previously separate trends converge into a single architecture.

Portolan Registry and Cloud-Native Geospatial Architecture

The Old Bargain

For decades, publishing geospatial data meant building systems around the data rather than around the user.

A government agency, university, NGO, or private company would acquire datasets, stand up servers, configure databases, publish APIs, manage permissions, maintain uptime, and hope users could successfully navigate everything required to access the information.

The infrastructure often became more complicated than the data itself.

The cloud-native geospatial movement challenged this assumption. Instead of asking how to build increasingly sophisticated servers, practitioners started asking a simpler question:

What if the files themselves were enough?

Cloud Optimized GeoTIFFs made raster data streamable. GeoParquet made vector data columnar, compressed, and cloud-friendly. PMTiles condensed massive tile collections into a single distributable object. STAC provided a common metadata language for describing ing datasets.

Suddenly, much of what once required specialized infrastructure could be accomplished simply and directly against files just sitting in object storage.

STAC Is Stepping Up As Connective Tissue

One of the most important aspects of this shift is STAC.

The SpatioTemporal Asset Catalog specification doesn't store data. Instead, it tells people and software what data exists, where it lives, and how to use it. Portolan builds directly on STAC as its organizational foundation, using STAC catalogs to make datasets consistently searchable and navigable.

That consistency matters far more than many people realize.

Without common metadata standards, every dataset becomes its own island. Every portal has its own rules. Every API has its own quirks. Every data provider requires users to learn a slightly different mental model.

STAC offers a shared vocabulary.

An analyst can move from a local municipal dataset to a national geospatial archive and encounter familiar structures. An application can discover assets without custom integration work. Increasingly, an AI agent can do the same thing.

The value isn't merely technical interoperability. It's cognitive interoperability.

Enter Portolan

Portolan takes this philosophy a step further.

The project describes itself as a serverless spatial data infrastructure built on cloud-native formats, strong metadata, documentation, and STAC catalogs. Rather than requiring a collection of databases, APIs, and application servers, a Portolan catalog can exist as files in object storage.

When I first encountered Portolan, what struck me wasn't the technology.

It was the restraint.

Many technology movements respond to complexity by introducing another platform, another server layer, another orchestration framework, or another interface abstraction.

Portolan's answer is almost the opposite.

Use open formats.
Document them clearly.
Organize them consistently.
Publish them where anyone can access them.
Then get out of the way.

Chris Holmes described the motivation particularly well in discussing Portolan's origins. He argues that traditional spatial data infrastructures never fully achieved their goal of making geospatial information broadly discoverable and usable. Portolan's answer isn't a new generation of complex systems. It's a collection of structured files and metadata that both people and AI agents can navigate.

Why Iceberg Suddenly Feels Even More Relevant

This is where Apache Iceberg enters the picture.

For most people, Iceberg is associated with data lakes, analytics platforms, and table versioning. It's often discussed alongside Spark, DuckDB, BigQuery, or cloud warehouse architectures.

But viewed through a geospatial lens, Iceberg solves another important problem.

Files are wonderful for distribution. Tables are wonderful for evolution. Datasets change. Corrections occur. New observations arrive. Schemas evolve. Historical versions need to remain reproducible.

Iceberg provides a mechanism for managing those realities while preserving an elegant, file-oriented architecture.

What's particularly interesting is the emergence of a STAC Iceberg Extension, which adds Iceberg-specific metadata to STAC Collections and enables clients to discover and connect to Iceberg tables using tools such as DuckDB, BigQuery, Spark, and PyIceberg.

That may sound like a small technical detail. I don't think it is.

It represents an attempt to bridge two worlds that have often remained separate:

the world of discoverable geospatial catalogs
the world of modern analytical table formats

Discovery Meets State

A useful way to think about the relationship is this:

STAC tells you what exists.
Portolan helps ensure that what exists is organized and understandable.
Iceberg helps manage how it changes over time.

Together they begin to form something that looks suspiciously like the next generation of spatial infrastructure.

Not a monolithic geoportal. Not a sprawling server farm. Not an expensive proprietary platform. Just catalogs, files, metadata, documentation, and versioned tables operating through open standards.

That architecture also aligns remarkably well with what modern AI systems need.

Agents don't care what vendor's portal you're running. They care whether they can locate data, understand it, query it efficiently, and reproduce results later.

A well-documented STAC catalog connected to cloud-native assets and versioned through Iceberg starts to look less like a GIS solution and more like a machine-readable knowledge layer for the physical world.

The Bigger Picture

In my article on the cloud-native geospatial stack, I described a broader transition away from heavyweight server-centric GIS architectures toward ecosystems built on GeoParquet, COGs, STAC, Portolan, DuckDB, and object storage: https://davidgsmith.net/cloud-native-geospatial-stack.html

What I'm beginning to appreciate is that these technologies are not competing innovations.

They're complementary pieces of the same puzzle.

GeoParquet makes the data efficient.
STAC makes it discoverable.
Portolan makes it publishable.
DuckDB makes it queryable.
Iceberg makes it durable and versioned.

Taken together, they point toward a future where spatial data infrastructure increasingly resembles the modern web itself: distributed, loosely coupled, standards-driven, and accessible to both humans and machines.

That's a far cry from the world of proprietary GIS silos and fragile API endpoints many of us grew up with.

And if the number of conversations I'm having about Iceberg lately is any indication, more people are starting to see where this is heading.

Further Reading

Portolan

https://www.portolan-sdi.org/
https://cloudnativegeo.org/blog/2026/09/introducing-portolan/
https://latlong.blog/2026/09/portolans-origin-story-as-told-by-creator-chris-holmes.html

My Previous Articles

https://davidgsmith.net/thoughts/portolan-and-the-quiet-reinvention-of-spatial-data-infrastructure.html
https://davidgsmith.net/cloud-native-geospatial-stack.html

STAC + Iceberg