    
    Typhon Engine
    /
    v0.0.1-alpha
  

Typhon - Intro

A database and a compute engine, in one process.

      Store it.
      ·
      Query it.
      ·
      Compute it.
      ·
      Profile it.
    

    Embedded  ·  C# / .NET  ·  In-process  ·  typhondb.io
    Technical Intro  ·  July 2026
  

    01 — The crossroad
  

Two ways to touch the same data.

Not two databases. Not two APIs to keep in sync. One store, one transaction, one set of entities — reached whichever way the work in front of you needs.

Database-like TARGETED

When you know which entities you want.

Indexed field predicates, ordering, pagination

Full ACID and snapshot isolation

Joins across typed entity links

tx.Query<Player>().WhereField(p => p.Level >= 50)

Wallet · roster · leaderboard · auth

ECS-like BULK

When you touch everything, every tick.

Contiguous SoA arrays — no per-entity lookup

100k+ components per tick

~1-5ns component reads

Spatial queries over the same entities

foreach (var c in clusters) c.GetSpan<Position>()

Movement · AI · physics · spatial

Same entity. Same transaction. Same snapshot. You don't choose at design time — a normal tick does both, and that combination is the whole point of the engine.

    02 — Translation, for one background
  

Five moving parts. One engine.

One background at a time. If your stack today is SQL Server + Entity Framework + SignalR, this is the direct translation — and the clearest way to see what “one engine” actually removes.

TODAY, IN .NET

SQL Serverseparate process

Entity Frameworkobject ↔ row mapping

DTOsserialize / deserialize

SignalR / WebAPIpush to clients

Rediscache the hot data

5 components  ·  4 representations of the same data  ·  ms

→

WITH TYPHON

ONE IN-PROCESS ENGINEno hop

Your struct is the stored row

ACID transactions & queries, local

Your systems run inside the store

Subscriptions stream deltas out

1 component  ·  1 representation  ·  µs

Not a faster SQL Server — a different shape. One process, one representation of your data, one toolchain. What you give up is on the next slide.

    03 — How it can be both
  

You pay for strictness only where you want it.

Every component type declares its own tier. But the cost depends far more on how you reach the data than on the tier.

STORAGE MODE

IN A SYSTEM LOOP cluster iteration

BY ENTITY ID point access

WRITE + commit

TYPICAL USE

VersionedDEFAULT

Full MVCC, snapshot isolation, zero loss

R0.74ns(1,351M/s)

Wn/a

R115ns(8.7M/s)

W550ns(1.8M/s)

749ns(1.3M/s)

Wallet · inventory · economy

SingleVersion

In-place store, durable at the tick fence

R0.77ns(1,299M/s)

W0.74ns(1,351M/s)

R80ns(12.5M/s)

W84ns(11.9M/s)

86ns(11.6M/s)

Position · velocity · health

Transient

Heap-only, deliberately gone on crash

R0.71ns(1,408M/s)

W0.74ns(1,351M/s)

R74ns(13.5M/s)

W85ns(11.8M/s)

84ns(11.9M/s)

Animation · input · scratch

Finding the entity is the cost

Locating one by id costs 65ns on its own, and every point figure includes it. Of an 80ns SingleVersion read, 81% is the lookup — not the read. In a system loop nothing is looked up, which is the whole ~100× gap.

WHAT YOU GIVE UP

Blittable structs only — no strings or references

Schema in code, not DDL

No arbitrary JOINs — the entity is the join point

* Measured 2026-07-29, engine rev 81e2a46 — AMD Ryzen 9 7950X, single-threaded per-operation cost, no per-commit fsync: these measure the engine, not the disk. Versioned has no system-loop write because a new revision cannot be written straight into storage. Bracketed figures are the reciprocal of the per-operation cost — operations per second at that latency, not measured concurrent throughput.

That's what your data is. When a write actually reaches disk is a separate choice — next slide.

    04 — When it hits disk
  

Commit always means atomic. It doesn't always mean on disk.

Durability is a separate axis from atomicity, and you pick where you sit on it. The question isn't “is my data safe” — it's how much recent work can a crash cost me?

    RISK WINDOW
    TIGHTER
    
    LOOSER
  

YOUR CALL, PER COMMIT

Immediate

CAN LOSE

nothing

Blocks until the write is fsync'd. ~15-85µs

Trades · payments · audit

YOUR CALL, PER COMMIT

GroupCommit

CAN LOSE

≤ 5ms

One flush interval, tunable. Returns in ~1-2µs

General request handlers

DECLARED IN THE MODEL

Tick fence

CAN LOSE

1 tick

Durable at the tick boundary. Writes cost ~40ns

Position · velocity · health

DECLARED IN THE MODEL

Checkpoint

CAN LOSE

to next cycle

Skips the WAL entirely. Bounded by timer or dirty-page threshold.

Bulk & regenerable state

Atomicity is not on this axis

No tier can leave a transaction half-applied. Atomicity, isolation and visibility are identical in all four — only the recency of what survives a crash differs.

    05 — So is it fast?
  

Yes — but only the matched comparison counts.

An engine offering fewer guarantees is faster because it does less work. So: against the durable engines that carry comparable machinery, and then on the route no key-value store has at all.

MATCHED AGAINST THE DURABLE ENGINES

How much faster Typhon is — every durable engine measured, wins and losses. Millions of ops/sec, 16 threads.

SQLITEROCKSDBLMDB

Batched reads 6.1×4.2×1.1× slower

Reads, one at a time 0.2 †3.4×10.8×

Updates 1.3 †12.8×15.1×

Mixed read / write 0.1 †30×0.06 †

Read-then-write 0.05 †34×0.03 †

Ordered range scan 2.3×1.6×3.6× slower

† SQLite and LMDB both permit one writer at a time by design — those rows are bounded by a single core, so we give the raw figure rather than a multiplier that would describe the workload, not the engine. RocksDB is multi-writer, so every RocksDB column is a straight comparison.

A DIFFERENT ROUTE — CLUSTER ITERATION

Identical work on identical entities, 100,000 of them. Only the route changes.

Point access — one id at a time 110 ns (9.1M/s)

Cell-by-cell — “everything near me” 0.94 ns · 117× (1,064M/s)

Flat sweep — the whole archetype 0.74 ns · 148× (1,351M/s)

3×3 cells — 3% of the world 1.09 ns (917M/s)

Cell-by-cell is the honest headline — the shape real simulation code runs in; the flat sweep means processing the entire world every frame. Bracketed figures are the reciprocal of per-operation cost, single-threaded — not comparable with the 16-thread throughput on the left.

Concurrency is the real story

Typhon is the only durable engine measured where writers scale — 15.0M writes/s while readers stay fast at 13.4M/s, at the same time. Every other durable engine serialises its writers.

* Where we lose: LMDB takes batched reads and range scans outright, shown above — our largest margin. Read-mostly workloads should use it.

We keep improving the competitors' adapters — we would rather publish a corrected number than a favourable one.

Single machine, no per-commit fsync — these compare engines, not disks. Full method and raw figures: benchmark/performance-comparison.md

    06 — It also computes
  

It's not just where data sits. It's where the work happens.

You declare what each system reads and writes. The engine derives the execution graph once, runs it across every core, and refuses to build an unsafe one.

Races become build errors

Two unordered writers of the same component won't compile a schedule — the engine rejects it at Build(), not in production at 3am.

Ticks, phases, all cores

Track → DAG → Phase → System. A single system can split its work across every worker and merge the results, inside one tick.

Bigger than memory

A paged, memory-mapped store — only the working set is resident, so the world can far exceed RAM. Most ECS frameworks can't leave memory at all.