An FFI wrapper over libxlsxwriter, and the memory numbers that made me reach for it.
I had a report endpoint that exported a table to .xlsx. It worked in testing. Then a customer with 400,000 rows hit it and the container OOM-killed the process.
The Dart package most people reach for is excel. It builds the whole workbook as an object graph in memory, serializes it at the end, and hands you the bytes. That is fine for a config sheet with 50 rows. It is the wrong model for a server generating large exports, and the package has had no release since 2024, so the memory behavior is not going to change. There is a maintained fork, excel_community, which is the one to use if you want pure Dart. It is better. It is still an in-memory model.
The measurement
I wrote 100,000 rows by 10 columns and measured peak RSS. Same data, four writers:
