Zanith · v0.1.0 · runtime-first

Your schema is
the runtime.

A SQL data engine that doesn't generate code. The schema parses once at startup into a runtime graph; queries compile to parameterized SQL on the way to the wire.

Read the architectural case Open the docs

no build stepno generated files191 / 192 tests88.97 KB ESM

zanith engine · schematic· v0.1.0 · runtime-first

● compile · 2.4µs / SELECT

▌ schema · 3 models

User6f

Post8f

Comment4f

step 01

Parser

22.9ms

step 02

Graph

0.73ms

step 03

Compiler

2.4µs

step 04

Adapter

<5µs

▌ compiled · parameterized

wire · pg2.4µs

SELECT id, email, role
FROM users
WHERE email ILIKE $1
LIMIT 10;

no build step · schema = runtime

$1 · params bound · never interpolated

parser→graph→compiler→adapter

v0.1 ready

schematic · zanith engine · v0.1.0 · drawn in code, no images

02 — The shift

Code generation made sense when runtimes were small. They are not, anymore.

Zanith treats the schema as data the engine reads at startup — not as a build target the engine compiles toward. The schema graph is the only artifact. Queries are typed, compiled, and executed against it without ever materializing a single generated file.

the old way · codegen ormcost rises with schema size

zanith · runtime-firstcost flat at any scale

03 — Anatomy

Four layers, small enough to read in an afternoon.

Every layer ships in the same package. None of them runs at build time. Click into /how-it-works for the deep dive.

01
layer · Parser
reads .zanith files at app start
lex · parse · validate — Chevrotain-backed, single pass
22.9ms
- · lexer · token stream
- · parser · CST → AST
- · validator · invariants
02
layer · Graph
the runtime structure, in memory
models · fields · relations · indexes — sub-ms lookups, 3.4MB at scale
0.73ms / 1k lookups
- · models, fields, enums
- · relations, indexes, uniqueness
- · type-inference projection
03
layer · Compiler
AST → parameterized SQL
expression tree · join planner · parameter binding — never interpolation
2.4µs / SELECT
- · expression tree · where clauses
- · join planner · projection
- · parameter binding ($1, $2, …)
04
layer · Adapter
pluggable wire driver
shipped: pg · postgres.js · planned: mysql · sqlite
<5µs engine-side
- · 5-method interface · drop-in
- · pg · postgres.js (shipped)
- · mysql · sqlite (planned)

04 — The compile step

From typed call to parameterized SQL in 2.4 microseconds.

Three steps. Build an expression tree from the args, plan against the graph, emit SQL. Parameters are bound by the driver — never spliced into the SQL string.

TS01 · call

8 lines


db.user.findMany({
  where: {
    email: { contains: '@example.com' },
    role: { in: ['ADMIN', 'EDITOR'] },
  },
  orderBy: { createdAt: 'desc' },
  take: 10,
});

typed against the schema graphready

build~1.2µs

AST02 · expression tree

SELECT

from·users

where·AND

ILIKE·email, $1

IN·role, [$2, $3]

orderBy·createdAt DESC

limit·10

3 params · planned

emit~1.2µs

SQL03 · compiled

6 lines


SELECT id, email, role, created_at
FROM users
WHERE email ILIKE $1
  AND role IN ($2, $3)
ORDER BY created_at DESC
LIMIT 10;

parameters bound · safeready

See more examples·How it actually compiles

05 — At scale

What happens at a thousand models.

Engine overhead, not end-to-end query time. Sourced from the engine's benchmark suite, re-run on every commit. The full table with comparison anchors lives on /proof.

Cost vs. schema size · illustrative10 · 100 · 500 · 1k models

codegen orms · 3 cost axes (client size · ts compile · deploy block)zanith · constant per-query overheadillustrative · sourced numbers on /proof

22.9ms: Schema compile
0.73ms: 1,000 lookups
2.4µs: SELECT compile
3.4MB: Graph footprint

Disclosed honestly: the test suite reports 191 of 192 passing — one flaky benchmark assertion, a ratio against a near-zero baseline. The figure above (2.4µs) is from the per-op assertion, which is stable.

06 — The day-to-day

Edit. Restart. Done in twenty-five milliseconds.

No generate command. No regenerated client to commit. No watch process to fight. Twenty-five milliseconds, end-to-end.

T+0sedit

T+22msreparse

T+25mslive

Frame 01 · editorT+0s

Edit schema.zanith

ZANITHschema.zanith

6 lines


model User {
  id    Int    @id @default(autoincrement())
  email String @unique
+ phone String? @unique
  name  String?
}

Frame 02 · terminalT+22ms

App reparse

shell · zsh~/zanith

$ pnpm dev

[zanith] schema.zanith — 4 fields → 5 fields

[zanith] graph rebuild · 22.9ms

[zanith] runtime ready · 1000 models

Frame 03 · resultT+25ms

New field live

TSquery.ts

5 lines


await db.user.findMany({
  where: { phone: { startsWith: '+1' } },
});
// → SELECT id, email, phone FROM users
//   WHERE phone LIKE $1

07 — Where this is heading

Six things runtime-first earns us.

What follows isn't a roadmap; it's a thesis. When the schema is data the engine reads — not code the engine compiles — these are the surfaces that become natural to build. Some are planned. Some are horizon. Two are speculative. None of them are promises.

planned01 / 7

Migrations as a first-class citizen

Schema diff that understands intent, not just structure.

Today the engine knows the runtime graph; tomorrow it knows how to evolve it. Compare two .zanith files, surface what changed, generate the SQL — with a human review step and a rollback path baked in.

schema diff · User+2 · −1

before

id Int @id

email String

− name String

role Role

after

id Int @id

email String

+ phone String?

+ name String?

role Role

generated DDL2 statements · safe

The single biggest gap between the current engine and a production-team replacement for Prisma. We won't ship Zanith for real apps without it.

horizon02 / 7

Schema Studio

An in-browser visual editor for the runtime graph.

Drag models onto a canvas. Wire relations. Watch the .zanith file update in real time. Watch the SQL diff. Let the graph tell you what it'll generate before you commit. The engine already exposes the graph as data; Studio is the surface that makes that data manipulable.

studio · canvas3 nodes · 2 edges

drag · drop · wire→ .zanith

When the schema is data, the editor is just another consumer. The runtime-first architecture earns this for free.

planned03 / 7

Multi-database, properly

Same compiler. Different SQL dialect emit step.

PostgreSQL today. MySQL/MariaDB and SQLite next. Edge runtimes (Cloudflare D1, Neon serverless) on the horizon. The architecture is database-agnostic; only the adapter set is single.

horizon04 / 7

Edge & serverless runtimes

Engines that wake up cold and stay light.

An 88KB bundle that compiles a query in 2.4µs is the right shape for the edge. A graph that holds 1,000 models in 3.4MB is the right shape for cold-start. We're not there yet — but the architecture is.

horizon05 / 7

Type-safe client SDKs

Browser code gets the same types as server code.

speculative06 / 7

Schema-aware natural language

Ask, with full schema context.

speculative07 / 7

Schema versioning, queryable

Ask the graph what was true last quarter.

Every schema change is a commit; every commit is a graph. Querying a historical graph means querying the data as it was, not as it is. We don't know exactly how this looks yet — but it sits naturally in a runtime-first world.

planned—has prerequisites in the codebase, target version namedhorizon—direction we'd build toward, no firm date yetspeculative—worth thinking about, careful about claiming

08 — Engineered by Fybyte

We picked the harder architecture.

Schema-as-runtime is harder to engineer and harder to make fast. We did it because the easy architecture was already built ten times over — and it stops being easy at exactly the scale we needed the engine to work.

Zanith ships from Fybyte's stack. Same engine, same tests, same compiler running in production as on this page. The rigor isn't a marketing claim; it's a constraint we live with daily.

Maker · Fybyte

Fybyte

An engineering company building the operating layer for modern operations. Zanith is the data engine; we use it for everything we ship.

established · 2024·headquartered · India·building publicly

Visit fybyte.com

Products shipped

Fyboard
AlphaCore
Zanith · v0.1

Engineering posture

open · sourced · cited

Working at

production scale, indie cadence.

seal · authenticcertified by · the people who run what they ship

the discipline · how we build

01KB · ESM88.97
Architecture as product
The runtime is 88.97KB. The graph holds 1,000 models in 3.4MB. Every byte was chosen, not accumulated. The engine is small enough to read in an afternoon — that's a design constraint, not a coincidence.
02tests · disclosed191 / 192
Tests over promises
192 tests run on every commit. Every figure on this site is sourced to a file you can grep. We disclose 191 of 192 passing and explain the one rather than rounding to all-green.
03fake benchmarks0
Sourced, not claimed
Comparisons to Prisma, Drizzle, and TypeORM will cite published benchmarks. Until those numbers are sourced, the marketing copy hedges with one consistent phrase. We won't manufacture credibility.
04from day oneProduction
Built where it ships
Zanith isn't a sandbox project. It's the data layer Fybyte uses in production — the same engine that handles real workloads, written by the same team that runs them.

The data layer hasn't moved in a decade. We're moving it — by rewriting the architecture, not by tweaking the codegen.

— the Zanith team·Fybyte · v0.1.0 · April 2026building publicly · written down so it holds

09 — Now shippingv0.2

Three things landed since the engine.

The roadmap moved. A web UI, a migrations system with risk scoring, and a recovery layer that lets a destructive op be walked back. Each is a real surface — not a checkbox.

§01studio

Studio · the web UI

Bundled with the engine. Eight tabs. Two levels — workspace and database.

Tables, catalog, security, SQL, schema, migrate, recover, search
FK drilldown · bulk edit · find & replace · sensitive masking
Lock graph · RLS inspector · permission matrix
EXPLAIN with plan history · watch query · result charts

See Studio

§02migrate

Migrate · with a risk model

Generate, plan, verify, apply. CI passes the score it's willing to absorb.

Drift-aware — auto-fill from a live database
Shadow-DB verification before up touches production
Risk 0–9 per op · destructive ops gated by an explicit flag
Per-step audit · roll back by N steps

See Migrate

§03recover

Recover · because drops happen

Soft-drop or archive every destructive op. Restorable until you cleanup.

Soft-drop renames · archive copies into a parallel table
Restore in one command — column or table
Export archive rows as CSV / JSONL / JSON before purge
cleanup --older-than 30d sweeps the artifacts

See Recover

One command to see itStudio runs against any connection your engine already has.


$ zanith studio --allow-sql
studio listening on http://127.0.0.1:4321

10 — Five doors

Pick the one that fits where you are.

door · 01

Read the architectural case

Why code generation is the wrong shape — eight chapters

The strongest argument for runtime-first, in eight chapters with the canonical numbers and the architectural diagrams.

door · 02

Your schema is
the runtime.

Code generation made sense when runtimes were small. They are not, anymore.

Four layers, small enough to read in an afternoon.

reads .zanith files at app start

the runtime structure, in memory

AST → parameterized SQL

pluggable wire driver

From typed call to parameterized SQL in 2.4 microseconds.

What happens at a thousand models.

Edit. Restart. Done in twenty-five milliseconds.

Six things runtime-first earns us.

Migrations as a first-class citizen

Schema Studio

Multi-database, properly

Edge & serverless runtimes

Type-safe client SDKs

Schema-aware natural language

Schema versioning, queryable

We picked the harder architecture.

Architecture as product

Tests over promises

Sourced, not claimed

Built where it ships

Three things landed since the engine.

Studio · the web UI

Migrate · with a risk model

Recover · because drops happen

Pick the one that fits where you are.

Read the architectural case

How it actually works

Real schemas, real SQL

The receipts

What's shipped, what's next

Your schema is the runtime.

Code generation made sense when runtimes were small. They are not, anymore.

Four layers, small enough to read in an afternoon.

reads .zanith files at app start

the runtime structure, in memory

AST → parameterized SQL

pluggable wire driver

From typed call to parameterized SQL in 2.4 microseconds.

What happens at a thousand models.

Edit. Restart. Done in twenty-five milliseconds.

Six things runtime-first earns us.

Migrations as a first-class citizen

Schema Studio

Multi-database, properly

Edge & serverless runtimes

Type-safe client SDKs

Schema-aware natural language

Schema versioning, queryable

We picked the harder architecture.

Architecture as product

Tests over promises

Sourced, not claimed

Built where it ships

Three things landed since the engine.

Studio · the web UI

Migrate · with a risk model

Recover · because drops happen

Pick the one that fits where you are.

Read the architectural case

How it actually works

Real schemas, real SQL

The receipts

What's shipped, what's next

Your schema is
the runtime.