Fixed a 5-bug concurrency cascade in my SQLite-backed SDK — went from silent failures to 50 workers, 0 errors in under 5s

Building StreamCtx (open-source Python SDK for LLM agent observability) and spent the last few days chasing what I thought was one SQLite locking issue. Turned out to be five separate bugs stacked on top of each other.

The cascade, in the order I found them:

1. WAL mode wasn't enabled — obvious first fix, but nowhere near enough on its own
2. A storage "singleton" that wasn't actually being reused across connections — each call was silently opening a fresh one
3. A connection leak: with self._connect() as conn: looks like it closes the connection, but sqlite3's context manager only manages the transaction, not the connection itself
4. Reads and writes competing for the same connection pool under load
5. Missing indexes on the column every query was filtering by

Fixed all five, then load tested with 50 concurrent workers. Before: sporadic failures under load. After: 50 workers, 0 errors, done in under 5 seconds — and I re-verified this on the actual published PyPI package, not just the local dev version, since I've been burned before by "works on my machine" claims in my own docs.

The annoying part: none of these bugs are exotic. Every one of them is "well known" if you already know to look for it. But the standard advice online stops at "enable WAL mode," which is necessary but not sufficient, and the docs don't really do a good job flagging the connection-closing gotcha.

Wrote up the honest before/after in the README rather than just claiming it's fixed — figured that's worth more than a badge.

Repo's open source if anyone wants to see the actual fix: github.com/streamctx/streamctx