Writing XLSX files involves two concerns that have nothing to do with each other:

OOXML correctness — relationships, content types, namespace declarations, theme references, drawing rels. Get these wrong and Excel may refuse to open the file or report a recovery dialog. The complexity is bounded but the surface is large.

Per-cell throughput — <c r="A1" t="s"><v>0</v></c> repeated millions of times. This dominates write time at scale.

Yet most libraries solve both via a heavy object model (Apache POI's User Model — correct but slow) or hand-roll everything (fast but you own every OOXML edge case).

There's a middle path: let POI handle correctness, let StringBuilder handle the hot path, split them at the format boundary.

The Existing Spectrum

All POI (User Model — XSSFWorkbook ):

✅ OOXML correctness handled

❌ Object allocation per cell ( Cell , RichTextString , CellStyle reference chains)

❌ Whole workbook lives in memory until write()

POI's SXSSFWorkbook improves memory by flushing rows to disk, but…