Meet sqlite-js-stream: Litestream, rewritten for Node.js in TypeScript It speaks the same LTX format as Litestream, so the two can read each other's files. Stream your SQLite WAL directly to S3 or local storage, and restore from it. But the real breakthrough is not just the port. It's how you deliver it. Litestream requires a Go sidecar, its own config, and a separate binary to manage on every deploy. sqlite-js-stream is an npm package that runs inside your Node.js process. No sidecars, no extra moving parts. That sidecar overhead? It's the main reason SQLite hasn't seen wider adoption in production. Matteo called it, and I agree. Here's the kicker: the entire port was built by an AI agent running locally on two DGX Sparks, with a human in the loop for planning, review, and final decisions. If SQLite backups were just one npm install away, would you finally run SQLite in production?

We never planned to build a memcached client. But every existing option became the bottleneck in our stack. Gateway request deduplication demanded a client that could handle real production traffic at scale. Nothing out there could keep up. When something sits this close to the hot path, I expect three things: strict opaque-token verification on every response, zero runtime dependencies beyond node:net, and real-world tests against memcached servers with authentication and TLS. This client delivers on all three. What’s the slowest link in your stack that everyone ignores?

Here’s a lesson from @matteocollina deep dive into our memcached client: A single pipelined connection outperformed a ten-connection pool from legacy @nodejs clients. Same server, same loopback, same Node version. 💡 The result? Our approach delivered triple the throughput of the fastest alternative. Why did the old clients need connection pools? They couldn’t pipeline efficiently. With a smarter parser, you unlock performance: pipeline on a single connection, parse by length for speed, and merge writes for efficiency. No extra cost, just better engineering. Pooling still matters when you need to handle large values that could block a pipelined connection. That’s what poolSize is for. But let’s be clear: pooling should solve real scaling problems, not compensate for slow parsing. How many connections does your busiest cache client open, and why?