Absolutely

But hidden in this is the failing of every sql-bridge ever - it’s definitely easier for a programmer to read customers(3).balance but the trade off now is I have to provide class based semantics for all operations - and that tends to hide (oh you know, impedance mismatch).

I would far prefer “store the records as plain as we can” and add on functions to operate over it (think pandas stores basically just ints floats and strings as it is numpy underneath)

(Yes you can store pyobjects somehow but the performance drops off a cliff.)

Anyway - keep the storage and data structure as raw and simple as possible and write functions to run over it. And move to pandas or SQLite pretty quickly :-)

customers[3]['balance'] seems like a reasonable middle ground, no?

It depends - most likely that’s storing as a language specific data structure (dict in python then serialised to disk). At this point we’re walking into harder to turn around decisions and might as well do it properly. It still really “it depends” …