Skip to main content
Overture Maps publishes open map data as Parquet files in a public S3 bucket. Its places dataset alone is about 81 million points of interest worldwide, in 11 GB of Parquet. This guide attaches that bucket to an Archil disk and queries it in place with DuckDB, with no download step and no AWS credentials. You’ll run ad-hoc SQL against the bucket from a persistent sandbox, save an extract as a DuckDB database on a second disk, put a small HTTP query endpoint in front of it, and run a one-off query with serverless execution.

Prerequisites

The Overture bucket is in AWS us-west-2, so this guide uses the aws-us-west-2 Archil region. Export an API key created in that region, then install the SDK for the language you’ll orchestrate from. You’ll also use curl to call the query endpoint.
Save each script in this guide in your project directory. Run TypeScript scripts with npx tsx <name>.ts and Python scripts with python <name>.py.

Create the disks and a sandbox

You need two disks:
  • overture-maps is backed by the public bucket, using the release/2026-09-23.0/ prefix as its root. Archil reads the Parquet files from the bucket as DuckDB asks for them, and caches what it reads.
  • duckdb-workspace is a regular Archil disk for everything you write: the DuckDB binary and the database you build.
A disk backed by a public bucket is read-only: Archil has no credentials to write to the bucket. Always mount it with readOnly: true (read_only=True in Python), in sandboxes and in serverless commands, and write your output to another disk.
This script runs inside the sandbox. It shows what the bucket contains, puts the DuckDB command-line binary on the workspace disk, and installs the DuckDB Python package for the query server you’ll run later.
setup.sh
Create both disks and a sandbox that mounts the bucket-backed disk read-only at /mnt/overture and the workspace at /mnt/work, then run the script:
The places theme is 16 Parquet files:

Query the bucket in place

Every Overture row has a bbox column with its bounding box, and the files store min/max statistics for it. When a query filters on bbox, DuckDB uses those statistics to skip the row groups that can’t match, so it only reads a small part of the 11 GB. This script finds the sandbox by name and runs two statements. The first breaks down the places in Seattle by category, straight from the bucket. The second saves every place in Washington state as a table in places.duckdb on the workspace disk.
In our runs, the Seattle query took under a second the first time, while DuckDB fetched the row groups it needed from the bucket, and about 0.15 seconds on repeat runs, which Archil serves from its cache. Saving the 382,501 Washington places took under a second. places.duckdb is an ordinary file on the workspace disk, so it survives the sandbox stopping, and anything that mounts the workspace can query it.

Serve queries over HTTPS

This server opens places.duckdb read-only and runs the SQL in each POST body. External file access is turned off and the setting is locked, so a query can read the places table but not other files in the sandbox or on the disks.
server.py
Upload it, run it as a supervised service so it restarts on failure and comes back when the sandbox reboots, and create a port token. Sandbox ports are private by default: a request without a valid token in the X-Archil-Token header gets a 401, so you don’t need to build authentication into the server.
Run the two export lines the script prints, then send a query from your machine:
Each request took about 0.2 seconds end to end from our machine, including the TLS handshake. The same request without the header returns 401. Hand the URL and token to a dashboard, a notebook, or an agent tool, and create a new token when this one expires.

Run a one-off query with serverless execution

For a quick question, you don’t have to go through the sandbox. Serverless execution runs a command in a short-lived VM, and archil.exec can mount several disks at once, each under /mnt/archil/<name>, which is also the working directory. This command mounts both disks read-only and runs the DuckDB binary from the workspace against the bucket, this time for Paris:
totalMs is measured by the server, from receiving the request to returning the result. In our runs the first Paris query took about 1.2 seconds, including starting the VM, mounting both disks, and reading the row groups it needed from the bucket. Repeat runs took under a second. Each serverless command is limited to 5 minutes, so use the sandbox for long-running work.

Clean up

Stop and delete the sandbox, then delete both disks. Deleting overture-maps doesn’t affect the public bucket.

Next steps