This is a technical walkthrough of the architecture we use to generate vector tiles at global scale from multiple open datasets. There is no database to provision or maintain, and tiles are served straight from object storage with no tile server required. It powers Amazon's last-mile delivery maps, 22+ specialized layers refreshed worldwide, and the underlying frameworks are open-source. The reusable design patterns, along with the open tools behind them, are what this talk is about.

The earlier system ran on PostgreSQL/PostGIS, and that database became the bottleneck for both scaling and faster map-data deployment. A worldwide refresh took 31 hours, 20 of them spent just building indexes. The database tier cost roughly $50K a month. No tile could be generated without first setting up the full database stack, and the SQL geometry transforms had no unit tests. The redesign removes the spatial database entirely.

The new architecture has two stages. First, Apache Sedona performs the cross-source joins, harmonizing OpenStreetMap-derived themes, Overture Maps, and Natural Earth into hive-partitioned GeoParquet on object storage, one partition per region. Second, Planetiler, the open-source OSM tile engine, runs per partition as the generation core. It reads those GeoParquet files directly, in memory, on a single machine, many partitions in parallel. No spatial database sits in the data path; columnar files are the only intermediate format.

In this presentation we cover four design patterns that are reusable on any geospatial data workflow.

• GeoParquet as a first-class tile source. Planetiler reads partitioned GeoParquet directly from object storage, with no PostGIS load and no spatial-index build, because partition pruning replaces the index and the columnar reader streams geometry on demand. The data lake becomes the input.
• Multi-source layers via per-zoom dispatch. A single logical layer such as water is fed by two source-specialized handlers registered on Planetiler's ForwardingProfile extension point (Natural Earth below z8, Overture above), so resolution scales with zoom and there is no hard cutover constant.
• Locality as a per-feature attribute. Each feature is tagged with a country code from an in-memory R-tree over administrative boundaries (sub-millisecond lookups), so locale rules like road-reference formatting and region-specific symbology branch on an attribute instead of forking the pipeline.
• A pluggable output layer. A small writer interface over Planetiler's tile output emits PMTiles, MBTiles, or sharded MVT (Mapbox Vector Tiles) straight to object storage with no tile server required, and selection adapts to land density per bounding box. Adding a format is one class, a pattern any Planetiler user can apply.

Parallelism only helps if the work divides evenly, and the planet does not. The build splits into geographic partitions generated in parallel, sharing nothing, so the critical path is the slowest single partition rather than a serial sum, and adding workers scales close to linearly. The catch is skew: an even spatial split starves some workers on empty ocean while others choke on dense cities. Routing work by a 256-cell land-density grid rebalances it, pulling total run time toward the median partition instead of the worst.

The point of the rewrite is not that the database is gone; it is that nothing was lost with it. Every legacy PostGIS capability was re-expressed as typed Java in Planetiler's encode loop:

The results: the worldwide build dropped from 31 hours to 3, database costs went to zero, and tiles came out about 10% smaller on average, which is less mobile data for a driver in the field. A fix for wrong gate flagged in the field now reaches every device in a corrected tile within 45 minutes. And because it is all open-source frameworks over open data, these building blocks are not Amazon-specific: the GeoParquet source reader, the per-zoom multi-source dispatch, the locality-as-attribute lookup, and the pluggable writer apply to any pipeline that turns open data into self-hosted basemaps.