Not long ago, spatial analysis meant downloading data. You’d find a shapefile or a GeoTIFF, pull it onto your local machine, and load it into desktop GIS software. This worked fine when datasets were measured in megabytes or gigabytes. But today, we're dealing with petabytes. Entire archives of satellite imagery, real-time sensor networks, and global-scale vector datasets are far too large to move.

This explosion in data size has led to a fundamental shift in how we work. Instead of bringing massive datasets to our analysis tools, we now send our analysis to the data. This core concept is known as 'data gravity'.

Think of it like a planet. A huge dataset has a gravitational pull, making it more efficient to run computations directly where the data is stored. This approach, often called 'push-down analysis', avoids the slow and expensive process of transferring terabytes of data over the internet. You send a small SQL query to the cloud, and the powerful infrastructure there does the heavy lifting, returning only the small result you need.

This shift is powered by a new kind of database architecture: the cloud-native spatial data warehouse. Unlike a traditional database like PostGIS, where computing power and storage are tightly coupled on a single server, modern platforms like Google BigQuery, Snowflake, and Amazon Redshift separate them.

This 'compute-storage separation' is a game-changer. Storage is cheap and can scale to hold immense datasets. Compute resources (the engines that run your queries) can be scaled up or down independently. Need to run a complex analysis for a few hours? You can spin up a powerful compute cluster, run your job, and then shut it down, paying only for what you use. This elasticity is impossible in a traditional, monolithic architecture.

While these platforms all leverage this modern architecture, they have their own flavours of Spatial SQL. A query to calculate the area of a polygon might look slightly different in BigQuery than in Snowflake, but the underlying principles are the same: performant, scalable analysis on massive geospatial data without moving it.

To work efficiently in the cloud, data formats themselves have evolved. Two key formats for modern spatial workflows are Cloud-Optimized GeoTIFFs (COGs) and GeoParquet.

A Cloud-Optimized GeoTIFF (COG) is a standard GeoTIFF file with a special internal organisation. It contains pre-calculated lower-resolution versions of the image (overviews) and is structured in a way that allows a client to request just the specific pixels it needs for a given view—a concept known as an HTTP GET range request. This means you can pan and zoom on a map powered by a massive raster file without ever downloading the whole thing. The server only sends the bytes required for your current screen.

GeoParquet is the vector equivalent. It's an extension of the Apache Parquet format, which stores data in columns instead of rows. Why does this matter? Most analytical queries only touch a few columns at a time (e.g., 'find the average population in all postcodes'). A columnar database can read just the 'population' and 'postcode' columns without having to process all the other data associated with each record. This makes queries incredibly fast and cost-effective, as cloud providers often charge based on the amount of data scanned.

Choosing the right infrastructure involves balancing scale, cost, and concurrency. For an application needing real-time analysis on constantly updating data for thousands of users, a cloud data warehouse with a dynamic tiling architecture is ideal. For a smaller, internal project with static data, a more traditional setup might suffice.

The key is to let data gravity be your guide. Analyse your data where it lives, using formats and architectures designed for the scale and elasticity of the cloud.