DIY file storage outperforms SQLite in simple ID lookups, but databases shine at scale. A Hacker News experiment tested three approaches: linear file scans, in-memory maps, and disk-based binary searches across Go, Bun, and Rust. 1M records saw Bun’s in-memory map hit 106k req/s vs. Go’s 97k, while Rust’s binary search delivered 45k req/s without loading data into RAM. SQLite lagged at 26k req/s but offered SQL flexibility. For early-stage apps, flat files with in-memory indexing may suffice, but relational databases remain critical for complex queries.

The binary search method sorted files by ID and used a fixed-width index (58 bytes per entry) for O(log n) lookups. This approach dropped latency to 1.4ms at scale, outperforming SQLite’s B-tree. However, appending new records breaks sorting, requiring periodic index rebuilds—a trade-off similar to LSM-tree compaction. Rust’s serde deserialization gave it a 3-6x speed edge over Go/Bun in naive scans.

In-memory maps dominated benchmarks with sub-millisecond latency but require RAM to hold all records. At 1M entries, this consumed ~55MB for indexes, fitting in modern caches. SQLite’s consistency (2ms latency across scales) made it a middle ground, though its B-tree overhead slowed pure ID lookups by 1.7x versus hand-rolled binary searches.

The practical takeaway: Use SQLite for SQL needs, binary search for read-heavy static data, and in-memory maps for ultra-low-latency services. For most startups, the “your own files” approach works until traffic exceeds 10k req/s—at which point databases become unavoidable. As one engineer noted, “At 1M records, Go’s linear scan takes over a second per request. That’s not tuning, that’s damage control.”