During the 2026 Esri User Conference we heard from several people they would like zero-copy external data integration. That means live data delivered on demand into ArcGIS without being written to an ETL copy, and ideally also without any intermediate server. This is a step beyond data virtualization, where a cache might be kept (for a very good reason, namely display performance). Just give me the data in my map they said.
OK, here it is.
What you're looking at is Overture Maps Foundation Places theme data read from AWS S3 and delivered into an ArcGIS Pro memory layer, within the current map extent, in seconds.
No intermediate copy, no database server in the delivery chain.
To step back a bit, I'm being a bit ambitious with the blog title, this isn't a supported Query Layer edition, but it may be a "good enough" approximation for many use cases, and not just for one session - you can refresh the data on demand.
How does this work? In the blog attachment is an ArcGIS Pro 3.7 toolbox containing a script tool Make Serverless Query Layer with two input parameters, a where clause filtering the data downloaded, and a boolean that determines whether the output schema has text fields with a default width or one inferred from the data, which I'm calling "tuning".
The source data, map extent detection and view definition are hard coded in the tool.
Here is what the view definition query looks like:
# Query S3
query = f"""select
id,
names.primary as primary_name,
basic_category,
taxonomy.primary as primary_category,
brand.names.primary as primary_brand,
concat_ws(',',brand.names.common) as other_brands,
concat_ws(' ',addresses[1].freeform,addresses[1].locality,addresses[1].postcode,addresses[1].region,addresses[1].country) as address,
array_to_string(taxonomy.hierarchy,' > ') as taxonomy_hierarchy,
array_to_string(websites,' ') as websites,
array_to_string(emails,' ') as emails,
array_to_string(socials,' ') as socials,
array_to_string(phones,' ') as phones,
operating_status,
confidence,
ST_AsWKB(geometry) as shape,
from read_parquet('s3://overturemaps-us-west-2/release/{release}/theme=places/type=place/*.parquet',filename=false,hive_partitioning=1)
where ST_Intersects(geometry,ST_MakeEnvelope({xmin},{ymin},{xmax},{ymax}))
and bbox.xmin >= {xmin} and bbox.ymin >= {ymin} and bbox.xmax <= {xmax} and bbox.ymax <= {ymax}
and {where};"""
We're querying GeoParquet in S3 using DuckDB, so the SQL syntax you see above is for DuckDB. Not shown, reading the Overture release name from a STAC catalog Overture maintain so we can inject the value into the query f-string value.
Things to point out in the code:
- DuckDB SQL functions are used
- Complex columns are flattened into a single value, for simplicity
- Both the spatial operator ST_Intersects and a bbox struct properties are queried
I'll let you inspect the script tool code at your leisure, but another notable aspect is data being read into an Apache Arrow table on its way to being a memory feature class. Arrow tables can be used in place of ArcGIS native feature classes as geoprocessing parameters, however I found a bug that necessitates double handling of the data (bouncing the data through a separate memory feature class rather than directly appending it to my target output) so you can expect faster performance when this is fixed.
To run the tool, first add the blog's attached toolbox to your project, then make a map or scene active at an extent that you're interested in - remembering all Places data in the extent will be read using the default "1 = 1" where clause - then choose whether to tune (or not) the text fields and click Run. Try out the sample where clauses in the script tool:
Here are the approximately 5,400 grocery stores in greater London, GB when my map was at 1:500K scale at run time:
Regarding tuning the text fields in the data: File-based formats (e.g. GeoParquet, CSV, JSON) usually do not travel with a schema definition (EsriJSON excepted). In ArcGIS, different tools make different choices about text field widths, which can lead to what's known in the industry as a "pathological schema", for example untuned data in this sample would create text fields 5000 bytes wide. This usually isn't a problem, but can be depending on where the data goes downstream, like slower performance in geodatabase or feature service, for big data. Because we're probably not dealing with big data using this sample, you can probably choose not to tune outputs, but in any event you have a workaround approach.
If you really do have document-scale columns in your data, you can run the tool without tuning then subsequently run Export Features to set your own column widths with the field map control in that tool.
If you would like a real "serverless query layer" then ask your Esri representative for the feature! I know a colleague testing out some approaches using the Pro SDK, but your input is invaluable.
