Integration
Five steps in order — fail readiness, wait for the load balancer, stop accepting, drain in-flight work, force-exit on a deadline — and a grace period longer than your slowest job. Measured on Node 23 and Docker 29.
Infrastructure
Measured on Postgres 16 at ten million rows. An exact COUNT(*) reads every visible tuple - 113,637 buffers, about 26 nanoseconds a row - and no index removes that. The estimate everyone reaches for, reltuples, was 23% wrong at the moment I needed it; the one nobody mentions was 0.008% wrong.
AI & Data
You do not — not with JSON.parse. On Node 23 the largest file fs.readFileSync can hand it is exactly 536,870,887 bytes, and past that you get ERR_STRING_TOO_LONG before the parser is ever called. Raising --max-old-space-size to 12 GB changes nothing, because the limit is on the string, not the heap.
AI & Data
MinHash with 128 permutations plus LSH banding at b=42, r=3. It found 99.47% of the near-duplicate pairs in 100,000 documents in 1.09 seconds with no false positives, against 8.3 seconds for a full pairwise scan of a corpus a tenth the size. Exact hashing found 0.12% of them.
Infrastructure
We measured plain HTTP against HTTPS on Node 23 over loopback, where there is no network to hide behind. A full TLS 1.3 handshake costs 0.20 ms of server CPU, steady-state throughput costs 23% on small responses, and session resumption — the thing everyone reaches for — saved nothing measurable.
Infrastructure
Brotli, but at quality 4 or 5 — never the default 11. Measured on Node 23 with node:zlib over realistic JSON. Brotli q4 produced a smaller 200 KB response than gzip -6 in 0.82 ms against 1.39 ms; brotli's default q11 took 179 ms for the same body, and 5.2 to 6.6 seconds for a 5 MB export. Includes t
Integration
I measured the two halves of the claim separately — binary serialisation against JSON, and HTTP/2 against HTTP/1.1. Binary decoding is about twice as fast, which is worth 0.03% of a request. The transport is where the real difference lives.
Infrastructure
SQLite in WAL mode committed 21,066 single-row inserts per second from one process, 3.7x what Postgres 16 managed on the same laptop. The second concurrent writer halved it and multiplied the worst commit from 1.1 ms to 237 ms. That tail, not throughput, is the ceiling.
Infrastructure
Measured on Postgres 16 at one million rows: every extra btree index costs 76 bytes of WAL per row written and about 1.5 microseconds per inserted row. One index halved insert throughput; eight left 8 percent of it. But on two of the four write paths the extra indexes cost exactly nothing.
Integration
One idle transaction that had read a single row made a Postgres 16 table grow 4x in five minutes under an ordinary write load. It blocked no queries and cost 0.2% of throughput — the damage was disk, and plain VACUUM did not give it back.
Infrastructure
Measured on Postgres 16 at one million rows. SELECT * reads exactly the same buffers as a narrow select, costs nothing on a cached primary-key lookup, and then costs 5x warm and up to 700x cold the moment it steps off a covering index. EXPLAIN ANALYZE hides most of the bill.
Infrastructure
We swept a read-mostly workload from 5 to 400 concurrent connections against a fixed CPU allocation on Postgres 16. Throughput peaks at about four times the core count. Past that, throughput degrades gently and latency degrades catastrophically — and the number that actually justifies a pooler is 2.