I Replaced My Entire Dependency Tree With the Standard Library (And Built a Quant Database)

Rishi Bharadwaj — Sat, 05 Sep 2026 13:15:40 +0000

Every dependency you install is a black box you don't control. You import it, cargo build swallows it, and somewhere in that tree of transitive crates is code you will never read, written by people you will never meet, that your production system now trusts completely.

I've been deep in quantitative finance and optimization math lately, and I kept noticing how fast we reach for a 40-crate dependency tree to do what is, underneath it all, just reading bytes off a socket and writing bytes to a disk. So I decided to find out what happens if you don't.

I threw away the dependency tree. All of it. And I built a time-series database anyway — in 72 hours.

What It Does

ZeroTick is a high-frequency time-series database for market order flow, built entirely on the Rust standard library. It:

Ingests raw TCP order flow at up to 250,000 ticks per second
Compresses every tick to disk in real time using hand-rolled Gorilla-style bit packing
Guarantees durability with append-only writes, self-describing frame headers, and automatic crash recovery
Drives a lock-free, TrueColor ANSI terminal dashboard
Serves live SVG charts straight to a browser, over the same TCP port, with no web server behind it

Here's the part I'm proudest of: cargo build doesn't touch the network once. Open Cargo.toml and the dependencies table is empty. Not "minimal." Empty.

[dependencies]
# Left intentionally blank

I didn't just take my word for it either — I ran cargo build against a completely fresh Cargo.lock and let Cargo tell me the truth about what it resolved:

[[package]]
name = "zerotick"
version = "0.1.0"

One package. Itself. No tokio, no serde, no axum, no ratatui. If it's in the binary, I wrote it or the standard library did.

Why Pure Rust (and Ditching the Python + Rust Split)

The industry-standard quant stack is Python for analytics, glued to Rust or C++ through PyO3 for the parts that actually need to be fast. In practice, that architecture is a latency tax you pay on every single tick.

Marshalling data across the Python/C FFI boundary burns microseconds you don't get back. Add Python's GIL and unpredictable GC pauses on top, and you've built a "low-latency" system with a garbage collector standing in the critical path. Going pure Rust end-to-end removed that tax completely — no FFI boundary to cross, no GIL to contend with, no background thread doing something to your heap that you didn't ask for. Every microsecond in the hot path is one I put there on purpose.

How It Works

Instead of an async runtime with a scheduler making decisions on your behalf, ZeroTick is an append-only, thread-per-connection engine built directly on POSIX primitives.

Ingestion binds straight to std::net::TcpListener. Each connection gets its own OS thread; ingest batches land on an mpsc channel and get picked up by a dedicated storage-writer thread, so a slow or malicious client can never block anyone else's writes.

Storage is a WORM (write-once-read-many) log. When you build storage without crates, you have to know exactly where the Rust standard library ends and the Linux kernel begins. To let queries run concurrently with active ingestion, I skipped the usual approach of a single shared, stateful file cursor and built reads around the OS's native support for absolute-offset access instead — so reads and writes never have to contend for the same lock, no matter how much data is flowing in.

Every batch of ticks gets Gorilla-compressed — delta-of-delta encoding for timestamps, XOR-delta encoding for prices — and appended behind a compact, self-describing header that carries enough information to reconstruct frame boundaries. That header makes crash recovery possible: on startup, the engine walks the frame boundaries and truncates anything that doesn't parse as a complete frame. No external WAL library, just a for-loop that trusts nothing.

Queries run through a per-symbol frame index and a single-pass math engine. If you calculate variance the naive way over a continuous data stream—summing the squares and subtracting the square of the sum—you will eventually hit floating-point catastrophic cancellation. As the total sums grow massive, the tiny price differences between financial ticks get rounded off into oblivion. Because my background is in optimization math, I knew the engine needed Welford's online algorithm. It incrementally updates the running mean and sum of squared differences tick-by-tick. This completely avoids precision loss and guarantees the calculation runs in strictly bounded O(1) space—a fixed, tiny amount of state—whether you're querying ten ticks or ten billion.

The multiplexer serves both its binary tick protocol and HTTP on the same port. The connection handler peeks at the first few bytes off the socket. If it sees GET, it parses just enough of an HTTP request line to pull a ticker symbol out of the URL path, runs the same query engine a raw TCP client would use, and hand-writes an SVG line chart directly into the HTTP response body as a formatted string.

Features

Zero-Dependency Architecture — no CVE supply-chain exposure, because there's no supply chain.
High-Speed Ingestion — sustained 250,000 ticks/sec over raw POSIX sockets.
Bit-Level Compression — delta-of-delta timestamps, XOR-delta prices, shrinking 16-byte ticks down to a handful of bits.
Crash-Safe Storage — self-describing frames plus automatic torn-write truncation.
Single-Pass Quant Analytics — mean, variance, z-score, Bollinger bands, and max drawdown, all computed in one O(1)-memory sweep via Welford's algorithm.
Native HTTP/SVG Multiplexer — live charts in a browser with no web framework.
Zero-Overhead TUI — TrueColor terminal dashboard powered by raw stdout writes.

The Inspiration

Modern enterprise software is bloated. We routinely ship web wrappers that burn gigabytes of RAM to render a line graph that a dumb terminal could've drawn in 1985. ZeroTick's interface is a deliberate throwback — the high-contrast amber-and-charcoal palette of vintage Bloomberg terminals, density over decoration, every pixel carrying information instead of padding.

War Stories: Everything That Went Wrong

Here's the thing nobody tells you about skipping dependencies: every bug you'd normally get to blame on a library is now, definitionally, your bug.

The 50GB Disk Exhaustion Loop

I wrote a chaos harness to simulate a power cut mid-flush by injecting garbage bytes into the middle of a data file. At 3 AM, it worked a little too well — it devoured my entire 50GB disk partition and locked up WSL solid.

Because I calculate every disk offset by hand, a single bit-shift misalignment in the XOR-delta price decoder made the recovery loop misread a frame boundary. Instead of surgically truncating the corrupted bytes, it decided the corruption was actually the start of a new (garbage) frame, and kept appending "recovered" nonsense forever. Fixing it meant sitting down with graph paper and mapping the exact binary layout of every buffer by hand before writing the self-describing frame headers that exist in the codebase today.

The Query That Never Got Faster

I'd built a clean binary search over frame headers by timestamp — O(\log n) to find your starting point in a symbol's history. Very pleased with myself. Except the index that binary search ran over was rebuilt from scratch, by scanning every single frame header on disk from byte zero, on every single query.

A query for "the last 60 seconds of AAPL" on a symbol with a year of history was paying to re-read a year of frame headers before it ever got to binary-search anything. The fix was to stop throwing the index away after every use. Queries went from "linear in the entire history of the symbol" to "logarithmic in the part you actually asked for."

The Random Walk That Wouldn't Walk

My synthetic ingest client generates ticks with a small pseudo-random step. Early on, I clamped the price at a hard floor to keep it from going negative. Except a symmetric random walk with a hard floor and no restoring force doesn't bounce off that floor — it gets stuck to it. Watch the dashboard long enough and every ticker eventually decays to a few cents and just sits there.

The real fix was a small Ornstein-Uhlenbeck-style mean-reversion term pulling the price back toward its starting equilibrium. Until it wasn't. I bolted a "chaotic" stress-test mode onto the benchmark, reusing what I thought was the same random-step formula — except I grabbed the version without the mean-reversion term. Turns out the step formula itself had a tiny, permanent bias baked in: centering a 0..199 random draw by subtracting exactly 100.0 instead of 99.5 leaves you drifting down by half a unit every single tick, forever.

When you hand-roll the math, you also hand-roll every way it can quietly misbehave.

Replacing the Ecosystem

Ripping out dependencies one at a time was the biggest time sink of the whole project, and also the most educational:

tokio → thread-per-connection I/O directly on std::net, with a hard cap on concurrent connections and a read timeout per socket.
axum + serde → a hand-rolled HTTP line parser that reads just enough of a raw request to tell a browser's request apart from a binary tick frame, and writes Welford's variance output directly into an SVG string. No routing tables, no async middleware, no struct derives, no JSON — just a strict allow-list on what goes into that string.
lz4 → hand-rolled Gorilla-style bit-packing: delta-of-delta encoding for timestamps and XOR-delta encoding for prices. Reimplementing a well-known algorithm from scratch doesn't really teach you the algorithm — it teaches you why the original authors made the choices they made, one edge case at a time.

The Takeaway

ZeroTick proves something I half-suspected going in and now believe completely: the Rust standard library is fundamentally complete for systems work. Not "good enough with caveats" — complete. TCP sockets, positional file I/O, atomics, threads, and enough control over memory layout to hand-roll a compression format — it's all sitting there in std, waiting for someone to actually read it instead of cargo add-ing past it.

You don't need a thousand dependencies to build something fast. You need to be willing to own every byte yourself — bugs, 3 AM disk-exhaustion incidents, and all.

DEV Community: Rishi Bharadwaj