Comment traiteriez-vous un CSV de quarante gigaoctets qui ne tient pas en mémoire ?

Traitez-le en flux. Ouvrez le fichier et itérez ligne par ligne, ou utilisez csv.reader sur l'objet fichier, pour qu'une seule ligne soit en mémoire à la fois, et poussez chaque enregistrement à travers des étapes génératrices plutôt que de construire des listes intermédiaires. Groupez les écritures vers la destination par lots de quelques milliers. Si le travail est limité par le CPU, découpez par plages d'octets entre plusieurs processus.

Rien n'est chargé en entier. Un objet fichier est déjà un itérateur sur les lignes, donc je lis ligne par ligne avec csv.reader et j'enchaîne des étapes génératrices pour le parsing, le filtrage et la transformation, ce qui maintient le pic de mémoire à environ un enregistrement quelle que soit la taille du fichier. Les écritures sont groupées, typiquement quelques milliers de lignes par insert, parce que les allers-retours ligne par ligne vers Postgres dominent tout le reste. Comme quarante gigaoctets prennent du temps, je rends le traitement reprenable : je suis l'offset en octets ou la dernière clé traitée dans un petit fichier d'état, je journalise la progression toutes les cent mille lignes, et je rends l'écriture idempotente avec un upsert pour qu'une relance ne puisse pas dupliquer. Si le parsing s'avère être le goulot plutôt que les entrées/sorties, je découpe le fichier par offsets et je confie les plages à un pool de processus, en prenant soin de m'aligner sur les fins de ligne. Honnêtement, ma première suggestion est souvent d'éviter Python pour le chargement et d'utiliser la copie en masse de la base, puis de faire la transformation en SQL, parce que c'est en général un ordre de grandeur plus rapide.