A validated reference run under the published 2 vCPU / 4 GB budget used 128 workers and sold 10,000 / 10,000 tickets with 0 double-spends while peaking at 10,633 combined read+update ops/s. mmap-backed reads stay page-cache friendly, the write path stays WORM-first, and contention fails fast instead of turning into a transaction queue.
The claim is mechanical, not theatrical: mmap-backed reads stay page-cache friendly, the write path stays WORM-first, and contention fails fast instead of turning into a transaction queue.
Workload
100k users / 10k tickets, 128 workers
Hardware profile
vCPUs
container memory cap
Result
10k/10ktickets sold and re-verified from persisted state
double-spends in 5.326 s
Peak QPS
10,633combined read+update ops/s
Read p90
5 msUpdate p90
20 msThe travel-room smoke is deliberately tight: 1,000 booking sessions compete for exactly 1,000 room rows through the same TCP server path. The final persisted recount is 1,000 / 1,000, with 0 failed sessions and no oversell.
Holiday Rush
20 hotels / 50 rooms each / 16 workers
Result
1000/1000booked and re-verified from persisted room rows
measured booking phase
Contention observed
lock conflicts
stale candidates retried
The hot read path is an indexed seat search over mmap-backed state, followed by short point reads. On the published 2 vCPU / 4 GB run, read p90 stayed at the 5 ms bucket while the system was selling out.
Each successful purchase is a single seat-state transition on the durable path, not a multi-statement SQL transaction storm. Update p90 stayed at the 20 ms bucket while 10,000 seats were claimed without oversell.
This published 5.326 s result is the local TCP horde path, not the separate QUIC/WebTransport demo and not a full commerce stack benchmark. What it proves is persisted inventory contention handling under load.
The engine is not relying on theatrical benchmarking. Every visible claim on this landing page maps to a mechanical property of the system and to a published artifact: mmap-backed reads, WORM-first writes, lock-free snapshots, and explicit correctness recount after the storm.
Read snapshots stay lock-free on the hot path. The point is not generic OLTP bragging; the point is stable read behavior while a small inventory surface is under write pressure.
In the bundled embedded comparative report, k-lani reaches 3648.82 TX/s with 32 concurrent writers while SQLite falls to 183.27 TX/s under the same lock-contention shape.
The bundled client/server smoke report shows 32.26 us p50 server point reads over 1,000 lookups and a compiled server binary footprint of about 1.6 MB.
for each worker: ids = query_intersect_ids(handle, "is_booked", u32_bytes(0), "rank", u32_bytes(rank), 64) pick up to 16 candidate seat ids try_lock(handle, id) fields = seek_fields(handle, id) if is_booked != 0: already_sold += 1; unlock(handle, id); continue replace(handle, id, encode_u32_fields(rank, seat_no, 1)) unlock(handle, id) sold += 1 after the storm: verify_sold_count() scans all 10,000 seats and recounts persisted sold rows
What this proves for a ticketing company: k-lani can serve as a narrow inventory and reservation engine behind an existing commerce stack. What it does not prove on its own: payment orchestration, cart UX, or direct browser-to-engine QUIC checkout in production.
The public GitHub repo now has the real starter guide: how to create the first table, which field types exist, how values are written, which errors come back, and how k-lani's explicit query commands work. This page stays short; the working details live in the repo.
Rust is the native embedded path. The guide shows an English customers table using Table::create, FieldType, FieldValue, secondary indexes, append, indexed seek, and lock/commit updates.
C# talks to k-lani-server over the binary TCP protocol. The guide explains the current codec pattern: map your own Customer model to schema-ordered fields, then call GetSchema, Append, SeekByField, Lock, Replace, and Delete.
TypeScript uses the browser/WebTransport edge through the k-lani-client WASM package. The guide is explicit that there is no REST fallback in the hot path: browser code sends binary command frames over QUIC/WebTransport.
Start here: GETTING_STARTED.md. It covers the first-table YAML, supported field types, Rust value writes, lock/commit updates, server commands, common error codes, and explicit query commands.
The owner command channel stays private until signed capability tokens, replay protection, rate limits, and audit are complete. Cloudflare can proxy the HTTP pages; direct UDP/WebTransport still needs a DNS-only route or a private tunnel.
Landing page and benchmark story.
Ticket horde correctness dashboard and raw artifacts.
Travel-room booking smoke: 1,000 sessions, 1,000 rooms, persisted recount.
Browser workstation backed by live table ticks.
Public preview repo with Docker runtime, benchmark bundle, checksums, and release docs.
Not theatrical. mmap-backed reads, WORM-first writes, and contention that fails fast. 10,000 tickets sold without double-spends, plus 1,000 Holiday Rush rooms booked and re-verified.