Wie würdest du eine vierzig Gigabyte große CSV verarbeiten, die nicht in den Speicher passt?

Stream sie. Öffne die Datei und iterier Zeile für Zeile, oder nutz csv.reader über das File-Objekt, sodass immer nur eine Zeile im Speicher liegt, und schieb jeden Datensatz durch Generator-Stufen statt Zwischenlisten zu bauen. Schreib gebündelt in Chunks von ein paar tausend. Ist die Arbeit CPU-lastig, teil sie nach Byte-Bereichen über Prozesse auf.

Nichts wird komplett geladen. Ein File-Objekt ist bereits ein Iterator über Zeilen, also lese ich zeilenweise mit csv.reader und verkette Generator-Stufen fürs Parsen, Filtern und Transformieren, was den Peak-Speicher unabhängig von der Dateigröße bei etwa einem Datensatz hält. Writes werden gebündelt, typischerweise ein paar tausend Zeilen pro Insert, weil Round Trips pro Zeile zu Postgres alles andere dominieren. Da vierzig Gigabyte eine Weile dauern, mache ich es wiederanlauffähig: Byte-Offset oder letzten verarbeiteten Key in einer kleinen State-Datei mitschreiben, alle hunderttausend Zeilen Fortschritt loggen und den Write mit einem Upsert idempotent machen, damit ein erneuter Lauf nichts duplizieren kann. Stellt sich das Parsen statt I/O als Flaschenhals heraus, teile ich die Datei nach Byte-Offsets auf und gebe Bereiche an einen Process-Pool, wobei ich auf Zeilengrenzen ausrichte. Ehrlich gesagt ist mein erster Vorschlag aber oft, Python für den Load ganz zu überspringen und die Bulk-Copy der Datenbank zu nutzen und die Transformation dann in SQL zu machen, weil das meist eine Größenordnung schneller ist.