# How do you build a geospatial lakehouse on Google Cloud? Build a geospatial lakehouse on Google Cloud with BigQuery and S2 for vector work, Earth Engine for managed raster analysis, and governance across the composition. Guide Build a geospatial lakehouse on Google Cloud with BigQuery and S2 for vector work, Earth Engine for managed raster analysis, and governance across the composition. ![Five translucent data planes of varied sizes tied into one system by a wide glowing band passing beneath them.](https://lakegeo.ai/_astro/build-a-geospatial-lakehouse-on-google-cloud.D34J2GvY_aJbdj.webp) By [Sean Knight](https://www.linkedin.com/in/thatsean/) Published August 6, 2026 Location data often spreads across analytical tables, imagery archives, machine learning workflows, maps, and operational applications. Each workload has different requirements, but the organization still needs consistent access controls, lineage, cost management, and definitions of trusted data. A [geospatial lakehouse](https://lakegeo.ai/learn/what-is-a-geospatial-lakehouse/) brings those workloads into one governed architecture. On Google Cloud, that architecture spans several managed services rather than one central product. The practical path becomes clearer when each service has a defined role and the controls extend across the full composition. ![Four connected service boxes for vector SQL, file store, managed raster, and pipelines standing on one band reading governance, identity, lineage](https://lakegeo.ai/_astro/learn-thematic-google-cloud-v2.BZYVVdDy_KJT3D.webp) _Four kinds of work in four managed services, standing on one shared band of governance, identity, and lineage._ ## How should the services divide the work? Vector data represents locations as points, lines, and polygons. BigQuery, Google’s serverless analytical warehouse, is the center for vector analysis. Its native GEOGRAPHY type supports spatial SQL. S2 is a discrete global grid system that divides the Earth into cells. BigQuery includes native S2 functions that can reduce the candidate data considered during spatial joins. Raster data represents space as a grid of cells. Earth Engine provides managed analysis for its environmental data catalog and registered imagery. BigQuery can use Earth Engine for zonal statistics. Zonal statistics are summary values computed over defined areas. Requirements outside the Earth Engine processing model move to Dataproc, a managed distributed processing service, or Dataflow, a managed service for data pipelines. These services can produce custom raster products and handle other distributed transformations. This division gives the architecture the strongest managed raster option among the three platform designs. It also creates more service boundaries to govern. Identity, lineage, orchestration, and cost controls must cover the entire composition rather than stopping at BigQuery. ## How do the six layers fit together? The [Geospatial Lakehouse Stack](https://lakegeo.ai/learn/what-is-the-geospatial-lakehouse-stack/) separates the architecture into six layers. On Google Cloud, each layer maps to a group of services. The first layer, ingestion, brings data into the environment. Cloud Storage, Google’s object storage service, receives files. BigQuery Data Transfer Service and BigQuery load jobs handle batch sources. Pub/Sub, a managed messaging service, works with Dataflow for streams. Storage Transfer Service moves provider archives. The second layer, storage and governance, stores that data and controls its use. BigQuery tables hold vectors, while BigLake managed Iceberg tables preserve open formats that can be used beyond one warehouse service. Cloud Storage retains files. Dataplex Universal Catalog provides governance metadata, and BigQuery Sharing distributes governed datasets. The third layer, spatial compute, performs spatial computation. BigQuery spatial SQL and S2 handle vector analysis. Earth Engine handles supported raster analysis. Dataproc or Dataflow runs custom raster pipelines. GraphFrames, a graph processing library, runs on Dataproc when relationships and networks require graph computation. The fourth layer covers machine learning and AI. BigQuery ML trains models inside the warehouse. Vertex AI provides custom model training and serving. Vertex AI Vector Search supports vector search workloads, while Gemini in BigQuery makes Google’s Gemini models available inside the warehouse. The fifth layer, orchestration, coordinates work. Cloud Composer manages pipelines that cross service boundaries. Dataflow runs continuous processing. Scheduled queries and Workflows handle simpler jobs. The sixth layer, consumption, presents results to people and applications. Looker and Looker Studio support analysis and reporting. BigQuery provides geospatial visualization. Cloud Run hosts applications that use Maps Platform for managed maps and routing. AlloyDB and Cloud SQL support low-latency application lookups through PostGIS. PostGIS is the spatial extension of the PostgreSQL database. ![Six-layer Geospatial Lakehouse Stack on Google Cloud, spanning BigQuery, Cloud Storage, Earth Engine, Dataproc, machine learning, orchestration, and consumption services](https://lakegeo.ai/_astro/learn-google-cloud-stack.ColvxA_U_Mff6V.webp) _The six layers of the Geospatial Lakehouse Stack on Google Cloud, service by service._ ## How does data become a governed product? Data gains structure and business meaning as it moves through five stages. The [Geospatial Medallion Architecture](https://lakegeo.ai/learn/what-is-the-geospatial-medallion-architecture/) names those stages acquire, bronze, silver, gold, and serve. During acquisition, Storage Transfer Service brings in archives, BigQuery Data Transfer Service connects managed sources, and Pub/Sub receives streams. Earth Engine catalog data can remain in place when copying it would add no value. The bronze stage preserves source material. Versioned Cloud Storage buckets retain original files under BigLake and Dataplex governance. Bronze BigQuery tables preserve tabular sources. The silver stage prepares data for analysis. Dataproc or Dataflow converts imagery into cloud-optimized raster formats, which arrange imagery for efficient remote access. BigQuery validates vectors and adds S2 indexes. Earth Engine assets can remain in their native environment when its catalog and processing model meet the requirement. The gold stage publishes governed BigQuery datasets with defined business meaning. Teams can register custom features and models through Vertex AI when their products require them. The serve stage connects those products to users and systems. Looker supports analysis. AlloyDB or Cloud SQL with PostGIS handles application lookups. Maps Platform supplies routing and maps, while BigQuery Sharing distributes data to partners. ![Five-stage geospatial medallion on Google Cloud from acquisition through bronze, silver, gold, and serving](https://lakegeo.ai/_astro/learn-google-cloud-medallion.B6BH9MbD_2v3gpY.webp) _Google Cloud services assigned to each stage of the geospatial medallion._ ## Where is this architecture strongest? Earth Engine distinguishes the platform from the other designs. It combines managed raster analysis with a large catalog of analysis-ready environmental data. Teams can calculate supported raster measures without first building their own distributed image-processing system. BigQuery provides a similarly managed path for vectors. Serverless spatial SQL removes the need to operate a database cluster for analytical queries, and native S2 functions support cell-based filtering. The consumption options also cover distinct needs. Maps Platform provides managed routing and map services. AlloyDB and Cloud SQL keep PostGIS-compatible application serving inside the same cloud environment. Together, these services support analytical, environmental, and operational uses without forcing every workload into one engine. ## Which limits affect the design? This architecture spans more services and operational boundaries than the comparable [Databricks](https://lakegeo.ai/architecture/databricks/) or [Snowflake](https://lakegeo.ai/architecture/snowflake/) designs. Access policies, lineage, orchestration, and cost controls must remain consistent across those boundaries. BigQuery provides spherical GEOGRAPHY calculations, but it does not provide a planar GEOMETRY type for calculations on a flat coordinate plane. Workflows that depend on projected coordinate systems require adaptation or another engine. S2 support is native. H3, another cell-based global grid system, depends on an extension such as the CARTO Analytics Toolbox. Earth Engine also has its own asset model, quotas, and catalog semantics. A team must account for those rules rather than treating Earth Engine as another collection of BigQuery tables. Graph processing and custom raster production remain separate concerns. They require Dataproc, Dataflow, or another engine when BigQuery and Earth Engine do not cover the requirement. ## Where should a team start? With this many services available, the failure mode is adopting more of them than the workload needs. Assign each workload to the narrowest managed service that meets its needs. Use BigQuery SQL and S2 for vector analytics. Use Earth Engine for supported raster analysis. Introduce Dataproc or Dataflow only when a required raster product or transformation falls outside Earth Engine. Apply governance, identity, lineage, orchestration, and cost controls as each service enters the design. The [Google Cloud page of the LakeGeo architecture](https://lakegeo.ai/architecture/google-cloud/) provides the formal service-by-service guide. Companion articles cover the same build on [Databricks](https://lakegeo.ai/learn/build-a-geospatial-lakehouse-on-databricks/) and [Snowflake](https://lakegeo.ai/learn/build-a-geospatial-lakehouse-on-snowflake/). For the first production workload, classify the requirement as vector analysis, supported raster analysis, or custom distributed processing. Then start with BigQuery, Earth Engine, or a Dataproc or Dataflow pipeline accordingly. ## About the author Sean Knight is a serial entrepreneur in the San Francisco Bay Area who builds products and companies around AI and geospatial data. He opened his first business, a retail computer shop, at 17, then began his career as an astrophysicist. From there he moved into remote sensing and machine learning, eventually flying drones over glaciers in Alaska and New Zealand to build 3D point clouds. Today he runs LakeGeo, consults on AI, and builds AI agents that run geospatial pipelines on platforms like Databricks. Find him on [LinkedIn](https://www.linkedin.com/in/thatsean/). See more LakeGeo in your Google Search and AI results. [Make LakeGeo a preferred source on Google](https://www.google.com/preferences/source?q=lakegeo.ai) Learn ## Continue reading [guide ### How do you build a geospatial lakehouse on Snowflake? Build a geospatial lakehouse on Snowflake with native spatial SQL and H3 in a governed center, plus Snowpark and container attachments for raster and graph work. ](https://lakegeo.ai/learn/build-a-geospatial-lakehouse-on-snowflake/)[guide ### How do you build a geospatial lakehouse on Databricks? Build a geospatial lakehouse on Databricks with native spatial SQL and H3 for vector work, governed file workflows for raster, and one catalog over all of it. ](https://lakegeo.ai/learn/build-a-geospatial-lakehouse-on-databricks/) LakeGeo ## Build geospatial work that can run in production. Read the open architecture guidance or talk to LakeGeo about a geospatial strategy and delivery engagement. [Read the publications](https://lakegeo.ai/architecture/) [Discuss an engagement](https://lakegeo.ai/contact/) Canonical URL: https://lakegeo.ai/learn/build-a-geospatial-lakehouse-on-google-cloud/