Round-trip from London to us-east-1 and back is 140ms. That's not a networking problem — it's an architecture problem. We moved the executor to the edge.
Every database in production today forces a fundamental compromise: your compute is fast and close to your users, but the moment a query hits the wire, it travels hundreds of milliseconds to a datacenter and back. That round-trip is a tax you pay on every read, every write, every user action.
Deltex was built to eliminate that tax entirely. By compiling a full PostgreSQL-flavored SQL engine to WebAssembly and deploying it across a global edge network, we move the query execution to where your users already are. The CDN stops being a cache and becomes the database runtime.
We're not a query gateway that proxies to a central database. We're not a caching layer over Postgres. The entire engine — parser, planner, executor, columnar storage — runs inside the Wasm binary at the PoP closest to your user.
We treat latency as a product decision, not a tuning parameter. Every line of code in Deltex exists to reduce the time between query and result.
SQL has survived 50 years because it's the right abstraction for relational data. We brought the full surface area to the edge, not a subset.
Wasm SIMD128, 128 MB heap, distributed KV. The edge is a real runtime. We reject the "limited compute" premise.
The whole engine is open source under MIT: parser, executor, columnar storage. Fork it, audit it, contribute.
View on GitHub →# Clone and build locally git clone https://github.com/trydeltex cd edgedb # Build the engine (targets wasm32-wasip1) fastly compute build --config engine.toml # Run locally fastly compute serve --config engine.toml # → http://127.0.0.1:7878 # Run 276 tests cargo test --target x86_64-unknown-linux-gnu
If you care deeply about systems programming, Wasm internals, query optimization, or distributed storage — we'd love to hear from you.