One engine.Both workloads.

Zyron runs three surfaces off one Rust codebase. An HTAP database takes transactions and analytics in a single engine, ZyronLake keeps shared-storage tables with branches and time travel, and a mesh lets one query reach every node.

Download v0.3.0 View on GitHub

Prebuilt binaries for Linux and Windows x86_64. Works with existing drivers and psql.

zyron-cliconnected · localhost:5432

$ zyron-server --data-dir ./dataWAL recovered, ready in 40 ms, listening on 5432 (TCP + QUIC)$ psql -h localhost -p 5432 -U postgrespsql connected, server Zyron 0.3.0zyron=> SELECT count(*) FROM orders AS OF TIMESTAMP '2026-05-06 09:00';1284905 rows, 1.3 mszyron=> CREATE BRANCH experiment FROM main;CREATE BRANCHzyron=> SELECT id FROM docs ORDER BY embedding <=> $1 LIMIT 3;3 rows, HNSW index scan, 0.8 ms

Scroll

65.1Ktps

Peak OLTP throughput

3.0GB/s

Columnar scan throughput

40ms

Cold boot to first query

703Ktxn/s

Durable group commit peak

Measured on a single 24-core machine, release build. Every figure comes from committed result files in the repository's benchmarks directory.

How Zyron works

01 / 04

Writes arrive

Transactions land over the wire. The hot path is lock-free, and every commit is fsynced through group commit before the client sees an acknowledgement.

02 / 04

The row heap

Fresh rows live in an MVCC heap tuned for OLTP. Point reads, updates, and high-concurrency writes run under snapshot isolation.

03 / 04

Columns form

A background thread compacts committed rows into .zyr columnar segments with per-column encoding. Queries filter the encoded data directly, and only surviving rows are materialized.

04 / 04

One mesh

Nodes peer over the wire, hosting a database, a lake, or both. A single SELECT reaches local heap tables, lake segments, and remote publications.

Keep scrolling to move the data

Platform

Three surfaces, one codebase

A database, a lake, and a mesh that ties them together. All three are reachable from any client language over the same wire protocol.

HTAP database

An MVCC row heap takes the transactions, the .zyr columnar format takes the analytics, and background compaction moves rows between them. One engine, one connection.

Explore

ZyronLake

A shared-storage table format on an append-only transaction log. Branches, time travel, versioned secondary indexes, and clustering, on local disk or object storage.

Explore

The mesh

Nodes peer over the wire. Any client can hit any node, and a single SELECT joins local heap tables to remote publications or a shared lake, with nothing in front.

Explore

Peer edges carry publications, subscriptions, and foreign scans. A query entering any node can reach all of them.

Features

The whole engine, built from scratch

No embedded SQL engine, no third-party storage layer. Zyron implements its own WAL, buffer pool, B+ tree, MVCC, parser, optimizer, vectorized executor, and wire protocol.

One engine, both workloads

Fresh writes land in an MVCC row heap tuned for OLTP. A background thread compacts them into the .zyr columnar format, and HybridScan reads both in a single operator.

Lock-free hot paths

LSN assignment, the WAL ring buffer, MVCC visibility checks, the buffer pool, and the B+ tree avoid mutexes on the query and write path entirely.

Durable by default

Every commit fsyncs the WAL through group commit before the client sees an acknowledgement. A committed transaction survives power loss, with no per-page fsync tax.

Time as a first-class dimension

AS OF TIMESTAMP and VERSION AS OF queries, copy-on-write branches, and bitemporal tables, with picosecond timestamps and hybrid logical clocks underneath.

Mesh, not monolith

A node can host a database, a lake, both, or run embedded. Nodes peer over the wire, and a single SELECT joins local heap tables to remote publications or a shared lake.

ZyronLake table format

Immutable .zyr files over an append-only transaction log. Branches, time travel, versioned secondary indexes, Z-order clustering, and change feeds live in the format itself.

Query-on-encoded

Dictionary, RLE, bit-packed, and FastLanes columns are filtered without being decoded. Only the rows that survive predicates are ever materialized.

Security inside the planner

Row-level security, column masking, ABAC, and three-state privileges are evaluated during query planning, not bolted onto an application tier.

Native search and ML

BM25 full text, HNSW vector search, and graph traversal share the engine with in-database model training, forecasting, and a feature store, all in plain SQL.

SQL

Standard SQL, plus the parts it was missing

Everything below runs over an unchanged PostgreSQL connection. No extensions to install, no sidecar services to operate.

Read any table as it was, by timestamp or by version.

-- Read the table as it existed at a point in time
SELECT * FROM orders AS OF TIMESTAMP '2026-05-06 09:00:00';

-- Or pin an exact committed version
SELECT * FROM orders VERSION AS OF 42;

Copy-on-write branches of the whole database, like git for your data.

-- Branch the database, experiment in isolation
CREATE BRANCH experiment FROM main;
USE BRANCH experiment;

UPDATE pricing SET rate = rate * 1.10;
-- merge back with conflict resolution, or drop the branch

Vector, full-text, and graph indexes are native engine features.

-- Native vector search
CREATE VECTOR INDEX ON docs (embedding) WITH (metric = 'cosine');
SELECT id FROM docs ORDER BY embedding <=> $1 LIMIT 10;

-- BM25-scored full-text search
CREATE FULLTEXT INDEX ON articles (body);
SELECT id FROM articles
WHERE MATCH(body) AGAINST ('rust database' IN NATURAL LANGUAGE MODE);

Train and serve models where the data already lives.

-- Feature store with point-in-time-correct joins
CREATE FEATURE GROUP customer_features AS
SELECT customer_id, ltv, orders_90d, days_since_signup FROM customers;

-- Train inside the database
CREATE MODEL churn AS TRAIN logistic ON customer_features;

Masking, row-level security, and temporal grants expressed as DDL.

-- Column masking as a policy
ALTER TABLE patients ADD MASKING POLICY ssn USING mask_ssn();

-- Grants with a validity window
GRANT SELECT ON revenue TO analyst
VALID FROM '2026-01-01' UNTIL '2026-12-31';

Retention, tiering, and archival are engine statements, not cron jobs.

-- Retention on the table itself
ALTER TABLE events SET TTL '90 days';

-- Tier cold data out to object storage
ARCHIVE TABLE old_events
WHERE created < '2024-01-01' TO 's3://archive/events';

Running in the next five minutes

Prebuilt binaries for Linux and Windows, no external dependencies, one command to a running server.

Download Zyron View on GitHub