The Geospatial Lakehouse Stack
A six-layer production stack and five-stage data lifecycle for governed geospatial systems.
Publication contents
The Geospatial Lakehouse Stack
The capability model describes what the production system must do. The lifecycle model describes the state of data as it moves through that system.
Architecture diagrams often mix services, processing steps, and data states in one stack, which obscures ownership. Separating them shows who provides each capability and whether a dataset is raw, prepared, or ready for a consumer.
Capability axis
Which capability performs and owns the work?
Lifecycle axis
What state is the data in, and what can use it?
Six capabilities form the production system.
The model states what a geospatial data platform must provide without prescribing one vendor, product, or service layout.
Ingestion
Managed incremental file ingestion from object storage, connectors for databases and applications, and a streaming path for live feeds. Vector, tabular, raster, and scientific array data enter through the same governed front door.
Storage and governance
Governed tables for spatial values, a governed file store for raster and point-cloud data, one catalog with lineage and access control across tables and files, and a sharing mechanism that avoids unmanaged export.
Spatial compute
Vector spatial SQL, a discrete global grid index such as H3 or S2, graph analytics, and a raster path using distributed libraries or a managed raster service.
Machine learning and AI
Governed feature management, experiment tracking, a model registry, scalable inference, model serving, and vector search reading and writing the same governed data.
Orchestration
Declarative or scheduled pipelines expressing the bronze, silver, and gold flow, incremental refresh, and streaming jobs that remain active for operational workloads.
Consumption
Dashboards with map rendering, natural-language query, custom applications, governed sharing, and low-latency serving to operational systems.
The layers assign responsibility.
One managed service may cover several layers, while a specialist engine may supply part of one layer. Every capability still needs an owner, an operating boundary, and a governed relationship to the rest of the system.
Five states connect a provider to a consumer.
Geospatial data moves through acquisition, preservation, preparation, product creation, and serving. Each state carries different guarantees and responsibilities.
- 01Acquire
Discover, license, task, receive, or transfer data from its provider.
- 02Preserve
Retain the source faithfully enough to reproduce every downstream representation.
- 03Prepare
Validate, normalize, index, and physically arrange data for its intended analysis.
- 04Productize
Create a governed output with explicit business meaning, quality, ownership, and lineage.
- 05Serve
Deliver fit-for-purpose representations to maps, applications, analysts, models, and partners.
State must be visible in metadata.
A valid source file is not necessarily analysis-ready, and an analysis-ready dataset is not automatically a business product. Catalog metadata should record the lifecycle state, producer, quality gates, and lineage of each governed representation.
Map each workload across both models.
A workload is a path through capability layers that moves data through lifecycle states.
Point-to-polygon enrichment, for example, acquires reference polygons and located records, preserves both sources, validates and indexes geometry into prepared data, runs spatial compute to create a product, orchestrates the flow, and serves the result. The lifecycle axis describes the changing data state. The capability axis identifies what performs each step.
Native capabilities and operated workflows
An implementation may satisfy a capability with a native service, a governed workflow, or a specialist engine connected to the primary data platform. The choice changes ownership, cost, reliability, and required skill. It does not change the lifecycle state the workload must produce.
Begin with one product.
- 1.
Name the decision and consumer.
Choose an output tied to a real business action instead of starting with a platform-wide migration.
- 2.
Map the capabilities.
Assign every source, store, engine, model, orchestrator, and serving surface to a layer and owner.
- 3.
Record lifecycle state.
State the quality, lineage, and reproducibility gate required before each dataset moves forward.
- 4.
Expose operating boundaries.
Label what the platform operates and what the implementation team must build and maintain.
Frequently asked questions
Why are capability and lifecycle separate models?
They answer different questions. Capability identifies which part of the system performs and owns work. Lifecycle identifies the state of data as it moves from a provider to a consumer. A single workload crosses both axes.
Does every workload use all six capability layers?
A production workload usually touches most layers, but it may not require a distinct component for every layer. One platform service can satisfy several capabilities as long as ownership and behavior remain clear.
Is the lifecycle model the same as bronze, silver, and gold?
The lifecycle model is broader. It identifies acquisition and serving as explicit states around preservation, preparation, and product creation. The separate Geospatial Medallion Architecture maps those states to acquire, bronze, silver, gold, and serve.
Can one dataset exist in several lifecycle states?
Yes. A source can remain preserved while analysis-ready and product representations are derived from it. Each representation should record its state and lineage so consumers know which guarantees apply.
How should a team start using these models?
Choose one bounded geospatial product. Map each system component to a capability layer, then record the lifecycle state of every important dataset. Missing ownership, duplicated components, and unstated quality gates become visible quickly.
- Identifier
- LGP-MOD-001
- Version
- 0.1, public draft
- Published
- License
- CC BY-SA 4.0
Suggested citation: LakeGeo, The Geospatial Lakehouse Stack, v0.1, public draft, 2026, https://lakegeo.ai/architecture/models/.
Release history
First public draft of the Geospatial Lakehouse Stack, including its capability layers, lifecycle stages, and adoption sequence.