MVCC row heap
Fresh writes land here first. Snapshot isolation and savepoints ride on MVCC, and pages live in a buffer pool with clock-sweep eviction.
Database
One engine takes both workloads
Fresh writes land in an MVCC row heap tuned for OLTP. A background thread compacts committed rows into .zyr segments with per-column encoding, and analytical queries run directly on the encoded data with predicate pushdown and late materialization.
Storage
Two stores, one scan
The row heap takes transactional writes, the .zyr columnar format takes analytical scans, and automatic background compaction moves rows between them. Queries never choose a side.
A background thread compacts committed rows into encoded segments while queries keep running. HybridScan reads whichever side holds the rows, in the same pass.
.zyr columnar segments
A background thread compacts committed rows into .zyr segments with per-column encoding, built for analytical scans.
HybridScan
One operator reads the heap and the segments together, measured at ~-2.5% overhead vs a heap-only scan.
Heap and lake tables are first-class in the same SQL, joined by the same HybridScan operator, whether they live on the local node, in a shared lake, or across the mesh.
Durability
Full durability, no per-page fsync tax
Every commit fsyncs the WAL through group commit before the client is acknowledged. Dirty heap and index pages are written by a background page writer and fsynced at explicit durability barriers, so an acknowledged transaction survives a power loss without paying a per-page fsync on the OLTP hot path.
~703Ktxn/sec
durable group-commit peak
~80.7µs
durable commit floor, device write
~70.9x
group-commit amplification, c=1 to c=512
Lock-free hot paths
These paths avoid mutexes on the query and write path entirely. Locks exist only on single-owner background threads.
LSN assignmentWAL ring bufferMVCC visibility checksbuffer poolB+ tree
Every figure here is extracted from committed benchmark result files, alongside the full tables on the performance page.
Query path
Parsed, planned, vectorized
A query enters as text and leaves as batches. The path runs in three stages, and each stage lives in its own crate.
01zyron-parser
Parse
A recursive descent parser with a Pratt expression core turns SQL text into a typed AST.
02zyron-planner
Plan
The cost-based optimizer reorders joins with dynamic programming, pushes predicates and projections into the scan, and decorrelates subqueries.
03zyron-executor
Execute
Vectorized, morsel-parallel operators move batches of rows through the plan instead of one row at a time.
Columnar
Queries run on encoded data
Encoded columns are filtered without being decoded. The scan works directly on the compressed representation and decodes only what survives.
dictionaryRLEbit-packFastLanes
~3.0GB/sec
.zyr scan throughput
~3.1x
metadata-aggregate pruning speedup
Skip before reading
Bloom filters and zone maps ride on segment metadata, so scans rule out data before touching it.
Materialize late
Predicates run on encoded columns, and only the rows that survive are materialized.
SQL surface
psql connects unchanged
Standard SQL, plus native extensions that go beyond it. The analytical surface is part of the engine, not an add-on.
CTEswindow functionsMERGEQUALIFYROLLUPCUBEGROUPING SETSGAP FILLprepared statementscursorsCOPY
Underneath it all is the PostgreSQL wire protocol v3 over both TCP and QUIC, so psql and existing drivers connect unchanged.
The full set of SQL highlights is in the README.
-- Read a table as it was at a point in time
SELECT * FROM orders AS OF TIMESTAMP '2026-05-06 09:00:00';
-- Branch the database, experiment in isolation, then merge or drop
CREATE BRANCH experiment FROM main;
USE BRANCH experiment;-- Native vector search
CREATE VECTOR INDEX ON docs (embedding) WITH (metric = 'cosine');
SELECT id FROM docs ORDER BY embedding <=> $1 LIMIT 10;Architecture
Each crate owns one layer
Zyron is a Cargo workspace where every crate depends only on the layers beneath it. A query enters at the wire and falls straight down the stack.
Clients
unchanged Postgres tooling
psql / driverszyron-clizyron-ctl
Connectivity
PostgreSQL v3, TCP + QUIC, TLS 1.3
zyron-wire
Orchestration
sessions, background workers, backup
zyron-server
Query path
cost-based, vectorized, morsel-parallel
zyron-parserzyron-plannerzyron-executorzyron-catalog
Native subsystems
in the engine, not an app tier
zyron-authzyron-versioningzyron-cdczyron-searchzyron-analyticszyron-pipelinezyron-lifecyclezyron-streamingzyron-types
Storage engine
heap, B+ tree, .zyr, MVCC, WAL
zyron-storagezyron-lakezyron-bufferzyron-wal
Foundation
errors, pages, hashing, PRNG
zyron-common
The full architecture, storage tiers, and crate map are in the README.
Storage tiers
Where the bytes live
Five tiers, each with one backing and one job. The engine moves rows between them so queries never have to.
| Tier | Backing | Purpose |
|---|---|---|
| B+ tree index | Resident in RAM, persisted via WAL + checkpoint | Point lookups, range scans |
| Row heap (OLTP) | Buffer pool with clock-sweep eviction | Recent and transactional rows |
| Columnar (.zyr) | Disk, hot segments cached in the buffer pool | Encoded analytical scans |
| ZyronLake (.zyr + log) | Object store or shared filesystem, versioned per commit, manifest-checkpointed | Analytical tables on shared storage. Branches, time travel, cross-engine reads |
| Write-ahead log | Append-only, group commit, fsync on commit | Durability and crash recovery |
The ZyronLake tier is a full table format of its own, covered on the lake page, and a single query can join any of these tiers to remote publications or a shared lake across the mesh.
Running in the next five minutes
Prebuilt binaries for Linux and Windows, no external dependencies, one command to a running server.