Basalt, queried from every Worker.
Bind Basalt to a Worker and query views from the edge. Requests route to the nearest of 38 regions, with typical reads under 20 ms.
Overview
How it works.
The Basalt binding gives your Worker a typed client that speaks HTTP/2 to the closest region. Connections are pooled across requests, and results can be cached in the Cache API for a TTL you set per view.
Setup
Set it up in three steps.
01
Add the destination
Create a read token and add the binding to wrangler.toml. The client is available on env.BASALT in every request.
# create a binding for the edge-api Worker basalt connect cloudflare --worker edge-api --role readonly
✓ token stored as secret BASALT_TOKEN
✓ binding BASALT added · nearest region fra-1 · 9 ms
02
Shape it with a view
Write plain SQL over the source. Basalt keeps the view current with every record and tracks lineage back to the topic, partition and offset.
CREATE MATERIALIZED VIEW revenue_by_min AS SELECT date_trunc('minute', ts) AS minute, currency, sum(amount) AS revenue, count(*) AS payments FROM payments WHERE status = 'captured' GROUP BY 1, 2;
03
Read it from anywhere
Every view is an endpoint the moment it exists. Call it over REST, connect with any Postgres client, or use the SDK from your app.
curl https://api.basalt.dev/v1/views/revenue_by_min?limit=5 \ -H "Authorization: Bearer $BASALT_TOKEN"
✓ 200 OK · 5 rows · served from eu-north-1 in 3.1 ms
Included
What you get.
01
Nearest region
Queries route to the closest of 38 regions based on the Worker's colo.
02
Typed client
The binding exposes your views as typed methods, generated from their schema.
03
Edge caching
Cache results in the Cache API with a per-view TTL and purge on update.
04
Read-only tokens
Scoped tokens can read named views only and are stored as Worker secrets.
Related
