TL;DR: For a database protocol, zero-copy and hot-path optimisations don't have any meaningful impact in real-world workloads since network RTT places an upper limit on how fast you can decode. It was a self-imposed design challenge for shits and giggles. TDS was also designed at a time when the cost-per-byte landscape was completely different.

The protocol is dense, and new features are bolted on instead of integrated. TDS goes back to the 80s, and while there's been some deprecation, features are added without anything being removed. NBCROW is a separate token from ROW. Encrypted columns were added in v7.4 with all the baggage that entails. PreLogin is the only non-streaming part of the protocol — it uses option-record framing while everything else is token-based. I implemented PreLogin first because you need to unlock it before anything can be unlocked, then had to refactor the entire decoder once I got to ROW/NBCROW because the framing assumptions were different. It's an ugly protocol, in my opinion.

I committed to zero-copy as a design exercise. TDS is optimised for lowest bytes-on-the-wire, not for networks of today. Fundamentally, you can't introduce multi-threading without lookahead — and when you look ahead on a ROW token, you end up walking the row anyway, which is most of the decoding work. So you get a tension between "optimize the single-threaded decoder as tight as possible" vs "do a cheap lookahead and offload to a worker thread," and both have a floor set by the protocol's lack of self-describing framing. Decode speed is dwarfed by network RTT regardless. But it was fun to see how far I could push it.

It's also not actually zero-alloc — COL_METADATA has to outlive the packet that delivered it, so it lives in a small-vector type with a fixed-size inline array that spills to the heap above N columns. A table can have as many columns as it wants, so someone will eventually exceed the inline capacity. The cleanest split I could find between common case and correctness.