Architecture
Deltex compiles a full SQL engine to WebAssembly and runs it inside the edge CDN itself. There is no origin database server — the executor is resident at every point of presence, so your query runs at the node nearest your user.
The Wasm executor
The engine is written in Rust and compiled to wasm32-wasip1, then executed by the edge runtime's Wasmtime/Cranelift AOT compiler. Because the module is pre-compiled and resident at every PoP, there is no cold start — first-request latency equals steady-state latency. It uses SIMD128, bulk-memory, and tail-call extensions for fast scans.
Three-tier storage
Data is persisted in the edge key-value store, sharded by size so small rows stay fast and large objects still fit:
| Tier | Size | Backing |
|---|---|---|
| Unified | < 2 MB | Single KV entry |
| Paged | 2–20 MB | KV with page index |
| Object | ≥ 20 MB | Object storage |
A columnar sidecar accelerates analytical scans, and a B-tree index layer powers point lookups and range queries.
Global edge
The engine runs across a global edge network. Reads are served from the closest node; writes use compare-and-swap against regionally-primary KV stores. The platform auto-selects a write region based on where your traffic originates.
Consistency model
Writes are strongly consistent within a region via CAS. Cross-region reads are eventually consistent and bounded by cache TTL — pass the X-Strong-Consistency: true header (or use Strong() in the SDKs) to force a synchronous, read-your-writes read when you need it.
For most workloads the default eventual reads are both faster and correct. Reach for strong consistency only on the read immediately following a write you must observe.
Edge caching
Query results can be cached at the edge with the /*+ CACHE(ttl=N) */ hint. The cache key is a hash of the SQL text, and cached responses are returned directly from the PoP with zero engine execution.