Uber, H3 and Pinot: GIS inside a digital product
Understand Uber’s published H3/Pinot analytical workflow, its limits, and a practical path from PostGIS analysis to a larger event architecture.
Editorial review: 2026-09-23
Uber's published examples show open geospatial components serving a precise product workload: finding and aggregating timely events near a location. They do not establish an organization-wide departure from ArcGIS, and they disclose no Esri migration savings that GeoSAT can reuse.
In its July 2021 Orders Near You engineering article, Uber described near-real-time orders and geographical deliverability as product requirements, using Apache Pinot and geospatial indexing. Its earlier H3 introduction described a hierarchical spatial grid for marketplace analysis. These are dated accounts of specific systems, not a description of every component Uber operates today.
What problem the components solve
A desktop map answers an analyst's interactive question. A product feature may need to answer a bounded geographic question repeatedly for many users, using recent events. That difference can justify a specialized serving model even when analysts continue to use desktop GIS elsewhere.
| Component responsibility | Role in the published pattern | What it does not establish |
|---|---|---|
| Operational event source | Records business events | That the analytical copy is the authoritative ledger |
| Ingestion into analytical storage | Makes recent events queryable | Zero delay or perfect handling of late events |
| H3 spatial indexing | Groups or narrows geographic candidates | Exact legal boundaries or road travel times |
| Pinot analytical queries | Serves the product's query workload | Universal superiority over PostGIS |
| Application rules | Decide usable product results | That spatial proximity alone means deliverability |
Apache Pinot's own geospatial indexing explanation describes indexing as part of spatial query execution. H3 is an indexing representation; it is not a routing engine, a cadastral authority or a substitute for the business definition of “near.”
GeoSAT interpretation: separate the record from the serving view
The transferable architectural principle is a separation of responsibilities:
Business transaction -> event/change stream -> query-oriented representation
-> spatial filter/aggregation
-> product response
Authoritative correction -> replay/update ------^
This is an explanatory pattern, not a copied diagram of Uber's current infrastructure. The authoritative system retains the transaction and its corrections. The analytical representation is optimized for a specific question and can be rebuilt. Consumers need a stated freshness expectation and behavior when the copy is delayed.
If a cancellation arrives after an order event, the derived count must be corrected. If an event is delivered twice, it must not count twice. If a timestamp is interpreted in the wrong timezone, a “last 15 minutes” filter can be wrong even when geographic indexing is perfect. These are data-product requirements, not details to postpone until after a fast demo.
A realistic LATAM adaptation
Consider a logistics operator asking, “How many currently actionable deliveries are near this dispatch point?” Define actionable status, event time, maximum staleness and the distance model. Straight-line distance, cell adjacency and road travel time answer different questions. A mountain, river crossing or restricted road can make nearby coordinates operationally far apart.
Begin with indexed PostGIS and a bounded query. Measure concurrency, latency distribution and freshness under realistic traffic. Add a separate analytical system only if evidence shows the simpler design cannot meet the task within cost and operating constraints. A municipal inventory of thousands of assets usually does not justify copying a global marketplace's entire infrastructure by reputation alone.
| Decision | Simpler baseline | Reason to test a separate analytical view |
|---|---|---|
| Moderate lookup traffic | Indexed spatial SQL | Read load interferes with transaction workload |
| Repeated regional counts | Materialized/maintained aggregates | High query concurrency with rapid refresh requirement |
| Large event history | Partitioned storage and bounded queries | Measured analytical workload exceeds chosen baseline |
| Exact parcel intersection | Authoritative geometry operation | Cell summaries remain only a candidate filter |
These are evaluation criteria, not numeric capacity thresholds. Hardware, query complexity, indexes and update rate matter.
Build a reproducible pilot
Generate fictional events with stable ID, asset/order ID, event time, ingestion time, coordinates and status. Include duplicates, late events, cancellations and corrections. Specify the expected result for a fixed time window before testing engines.
Compare the baseline and candidate with the same semantic query. Record p50/p95/p99 response duration, error rate, ingestion delay, result correctness, resource use and operating cost. Measure cold and warm paths and include an update/replay exercise. Keep raw request definitions and versions so another team can reproduce the measurement.
A fast query that returns stale or duplicate orders is not a successful pilot. A system that requires an unavailable specialist for every incident may also fail the operating requirement. The migration economics guide includes internal labor and support for this reason.
What this means for an ArcGIS strategy
Open technologies can sit inside product workflows without replacing every GIS tool in the company. An organization may retain ArcGIS for a specialized analysis or editing task while building a product API on open components. The meaningful question is which workload benefits from a different contract, data model or operating cost.
Use the architecture blueprint to place that service in the wider platform, and PostGIS query optimization to establish a credible baseline before adding a distributed engine. Cite Uber as evidence that the workload pattern exists, not as proof of your own performance or savings.