March 5, 2026
700 columns vs structs: cage match
Nobody ever got fired for using a struct
Until 700 columns walked in and everybody grabbed popcorn
TLDR: A super-wide SQL table compiled into a giant Rust struct slowed things down. Comments split between “keep it simple” and “split data for speed,” mixing jokes, outrage, and practical advice—highlighting how data shape choices can make or break performance in real systems.
A Rust-heavy post from Feldera declared "nobody ever got fired for using a struct"—then showed a customer workload with a table so wide it needed hundreds of optional fields. Translation for non-devs: they turned a mega spreadsheet with lots of blank cells into one giant, slow box. The comments? Pure chaos.
The strongest opinion blast came from SoftTalker, who basically yelled, "700 columns? Absolutely not," while others argued some databases default to lots of blank-friendly columns. The design nerds hit back with: stop cramming everything into one box—try splitting data up for speed (see data-oriented design). SigmundA got spicy, saying Feldera accidentally rebuilt a classic database row with a "null map"—the tech version of sticky notes marking empties—and pointed to Postgres internals.
Meanwhile, the humor brigade arrived: astrostl joked they’ll fire someone “for using a struct” just to prove the headline wrong, and dyauspitr declared, “No one has written a struct in 10 years.” The drama boils down to two camps: keep structs simple vs reshape data for performance. Either way, the internet turned a memory layout into a meme—and yes, we all brought popcorn.
Key Points
- •Feldera compiles SQL queries into a Rust program that incrementally evaluates results, representing each table row as a Rust struct.
- •A customer’s workload with a very wide SQL table (hundreds of mostly nullable columns) triggered a significant performance slowdown.
- •Nullable SQL columns are mapped to Rust `Option<T>` fields, producing a struct with hundreds of optional fields in this case.
- •Using the `memoffset` crate, the author inspected the struct’s memory layout, revealing sizes and alignments (e.g., Option<i32> ~8B, Option<bool> 1B each plus padding).
- •The analysis highlights how optionality and alignment/padding in large structs can inflate memory footprint and contribute to performance issues.