HTAP · ONE ENGINE
One database for transactions and analytics.
EzraDB is a Rust HTAP database that runs your transactions and your analytics on one copy of your data — PostgreSQL-18 wire-compatible, with a vectorized columnar engine that beats Postgres, TimescaleDB, and ClickHouse on TPC-H, plus native time-travel, ASOF joins, and deterministic backtesting.
THE STATUS QUO
Two databases, one fragile pipeline in between.
You run Postgres for transactions and a warehouse for analytics, wired together with ETL. The pipeline breaks, the dashboards lag, the bill doubles, and your "real-time" analytics are an hour old.
Three systems to run, one copy too many.
THE SHIFT
Transactions and analytics on one copy of your data.
EzraDB unifies a RocksDB-backed transactional row engine and an Arrow/Parquet vectorized column engine on one MVCC timeline, behind a single Postgres front door. Pick the engine per table with USING — same SQL, no pipeline.
One panel, two engines, no copy in between.
CREATE TABLE accounts (id INT PRIMARY KEY, owner TEXT, balance NUMERIC) USING row; -- OLTP
CREATE TABLE events (id INT, payload TEXT) USING column; -- OLAP
CREATE TABLE ticks (ts TIMESTAMPTZ, sym TEXT, px NUMERIC, vol BIGINT) USING hybrid; -- HTAP
TPC-H · SF1
The only Postgres-compatible engine that finishes all 22.
Derived from TPC-H, SF1 · 2026-05-23 · single-tenant exclusive host · 10 warmup / 30 timed
StarRocks runs its tuned dialect; EzraDB runs canonical SQL. Multipliers on the shared query set. SF10/SF100 pending.
Full methodology & reproDROP-IN
Speak Postgres. Change nothing.
EzraDB implements the PostgreSQL-18 wire protocol and reads your postgresql.conf and pg_hba.conf. Point psql, your driver, or your ORM at it and go — no rewrite.
# EzraDB speaks the PostgreSQL wire protocol — any PG client connects
psql -h your-host -p 5432 -U ezra -d ezra -c 'SELECT version();'
-- PostgreSQL 18.0 (EzraDB 0.1)
BUILT FOR TIME-SERIES
A quant engine inside your database.
Native ASOF joins, AS OF SYSTEM TIME time-travel, candlestick/VWAP aggregates, and streaming ingest — plus a BACKTEST engine with walk-forward folds and built-in Sharpe, Sortino, Calmar, and max-drawdown.
Deterministic — same seed, bit-identical P&L.
SELECT q.ticker, q.ts, t.price
FROM quotes q
ASOF JOIN fills t
ON t.ticker = q.ticker AND t.ts >= q.ts -- most recent fill at/after each quote
ORDER BY q.ts;
DATA GRAVITY
Move the compute, not the data.
Every hop out of the database costs you — serialization, the network, staleness, and another system to run. EzraDB keeps compute where the data lives: functions, backtests, and incremental views run inside the engine. And as EzraDB goes distributed, the compute follows the data across nodes.*
The data — all of it — makes the trip. Every run, every night, every retry.
A few kilobytes of code make the trip. The data never leaves the engine.
Compute in the engine
PL/pgSQL and JavaScript (PLV8) functions, deterministic backtests, and incremental materialized views — and pgforge, our TypeScript data layer, compiles your typed business-logic guards into the database itself.
Zero data motion
No ETL hop, no export to a Python worker, no cache round-trips. OLTP, OLAP, search, and KV share one copy of the data.
Compute that scales with the data*
Distributed execution routes functions to the nodes that own the data — fanned out by volatility and parallel-safety — with TypeScript deployed via pgforge and GPU-accelerated aggregation on the horizon.
*In development — not yet production-ready.
pgforge · THE TYPESCRIPT DATA LAYER
The database is the guard.
pgforge is our TypeScript data layer, built alongside EzraDB. You author schemas and business-logic guards in typed TypeScript; pgforge compiles them to PL/pgSQL that the database itself enforces — verified in CI, not asserted in the app. Rules hold no matter which service, script, or human touches the data.
Validate before data is touched
Verify, replay, and behavioral test kits run your guards against an ephemeral database in CI — 2,070 tests stand behind the compiler itself.
Built for EzraDB
A first-class EzraDB dialect with a capability matrix, integration-tested on the wire — schemas, guards, RLS, and the compiled job queue. Even BACKTESTs can be authored from TypeScript.
Where it goes next*
Deploying TypeScript through pgforge directly into the engine — the same code, running where the data lives.
*In development — not yet production-ready.
Explore pgforge →const E = defineErrors({
itemsPositive: { code: "PF001", message: "order items must be greater than zero" },
})
emitEntity({
source: orders,
pk: "id",
orgScope: "organization_id", // writes forced to the active workspace
// closed expressions, never raw strings — injection-safe by construction
guards: [{ when: le(newCol(orders, "items"), lit(0)), error: E.itemsPositive }],
})
// → compiles to PL/pgSQL: the database enforces the rule
Typed on your side, enforced on the database's side — the guard compiles to PL/pgSQL and travels with the schema.
CORRECTNESS
Verified where it counts.
Formally model-checked
TLA+ and Stateright models of Raft replication, leader-lease, MVCC/SSI serializability, parallel-commit, online-DDL.
Deterministic simulation
FoundationDB-style DST covering all five Raft safety properties, with seed-reproducible replay.
Metamorphic fuzzing
SQLancer-style TLP and NoREC query-correctness fuzzing.
Mutation-gated
CI-gated mutation testing on correctness-critical crates.
CONSOLIDATE
More of your stack, in one engine.
UNDER THE HOOD
Vectorized execution, a Rust-native optimizer, no JVM.
Vectorized columnar
SIMD codecs (Gorilla, Delta, Dictionary, RLE, FOR), PREWHERE, zone maps.
Rust-native optimizer
A Cascades cost-based optimizer in Rust — no JVM.
Predictable tails
Rust, no GC pauses. Latency you can reason about.
USE CASES
Built for data that can't wait.
HEADS-DOWN BUILDING
One engine. Many superpowers.
EzraDB is pre-1.0 and we're not taking signups yet — no forms, no waitlists. Dig into what the engine can do, and watch the roadmap to see what ships next.