TachyonDB status

Capabilities

• Authentication: PBKDF2-HMAC-SHA256 password KDF (no placeholder hash); per-user hashed credentials file; no default login — credentials are set at first run (tachyond --passwd <user>); failed-attempt rate limiting and lockout.
• Durability: write-ahead journal with per-record CRC-32C and LSNs; configurable fsync policy (off / interval / always); replay on startup; snapshot + journal truncation. Crash-recovery (kill -9 mid-write, restart, verify) is a passing C test.
• Transactions: BEGIN / COMMIT / ROLLBACK with atomic per-frame apply via an in-memory undo log.
• Concurrency: single process, one non-blocking select() event loop serving many clients; all sockets non-blocking; TCP_NODELAY.
• Extended ops: EXT JOIN, SPLIT, REINDEX, COMPRESS — implemented and tested.
• ORDER_BY: ORDER_BY1 / ORDER_BY2, ascending or descending (bit7 of the field byte), filter-aware, with a bounded top-k path under LIMIT and OFFSET.
• TacyonMem (in-process): the engine links directly into local callers (CGI / URLChannel); the record arena is mmap'd from shared memory under /dev/shm, so the data path has no socket and no framing. Volatile — for hot read paths, not the durable system of record.

On-command probe

Click tachyondb_status.cgi for a live TCP probe of 127.0.0.1:7447 (override with Apache env TACHYON_HOST/TACHYON_PORT) and the in-process shm arena under /dev/shm.

This static page does not invent a “running” state. If the CGI reports no listener, start tachyond on the host first.

Fair benchmarks vs SQLite 3.46.1

Every row is labelled with transport and durability, and compares like with like. The networked rows use the identical client, wire framing, loopback and workload against both tachyond and a minimal single-process select() TCP server that wraps SQLite and speaks the same protocol — so only the engine differs. The in-process rows compare TacyonMem (engine linked in, arena in /dev/shm) with SQLite :memory:, both volatile. Keyed KV workload (put/get), 64-bit Linux build. All numbers are from real runs on one host; treat absolutes as representative, not a production SLA.

1 · In-process (no TCP) — volatile, single thread

Small records favour TacyonMem (~3–7×); 64 KiB–1 MiB are memcpy-bound and roughly even.

2 · Networked, loopback TCP — durable, 1 client

Tachyon fsync=always vs SQLite synchronous=FULL + WAL.

Durable writes are close and fsync-bound on both. Durable reads are SQLite's win here: its WAL lets readers proceed, while Tachyon's current single-thread journal/snapshot maintenance stalls the loop (p50 stays ~18–40 µs but the tail drags throughput). Noted as a known limitation.

3 · Networked, loopback TCP — volatile, 1 client

Tachyon fsync=off vs SQLite :memory:.

Non-durable over TCP: Tachyon leads at every size tested.

4 · Networked, loopback TCP — volatile, 128 clients

Tachyon fsync=off vs SQLite :memory:, 128 concurrent clients on the one select() loop.

5 · Networked, loopback TCP — durable, 128 clients

Tachyon fsync=always vs SQLite synchronous=FULL + WAL, 128 clients.

How to read

• Compare only within a table: same transport, same durability, same client count.
• In-process and networked numbers are never mixed — an in-process op has no socket, a networked op does.
• Durable reads under fsync=always are a known weak spot (see table 2/5 notes); non-durable and in-process reads are not affected.
• All timings are measured wall/percentile values from the C bench harness (bench/run_fair.sh) — not estimates.

ChannelVault sticky store

• Redis ingress (CGI): podsticky:<user>
• TacyonMem / TachyonDB path: /pod/<user>/sticky (Object, magic PSTK)
• External BQL radio on Pod Configuration when the DB URL differs

Operator — reproduce the fair benches

# Build (64-bit Linux, no libc) and run the full C test suite
cd /workspace/tachyon && bash build_linux.sh && bash tests/run_all.sh

# Fair, labelled benchmarks (networked + in-process, matched durability)
#   needs the SQLite 3.46.1 amalgamation in SQLITE_DIR
SQLITE_DIR=/path/to/sqlite-amalgamation-3460100 bash bench/run_fair.sh