Comment exporter une base PostgreSQL en CSV, JSON et Parquet

Exporter une base PostgreSQL est une opération courante : sauvegarde ponctuelle, transfert vers un autre outil, archivage analytique, ou simplement partage d'un jeu de données. PostgreSQL ne propose pas un seul format d'export, et c'est tant mieux : CSV, JSON et Parquet répondent à trois besoins distincts, avec des outils et des coûts différents.

Ce guide passe en revue les commandes natives PostgreSQL pour chaque format, les outils tiers qui automatisent la tâche, et les critères pour choisir le bon format selon le contexte.

Exporter en CSV avec COPY

La méthode native pour produire un CSV depuis PostgreSQL est la commande COPY. Elle s'exécute côté serveur, lit la table directement depuis le moteur et écrit le résultat dans un fichier. C'est l'approche la plus rapide et la plus économe en mémoire, parce qu'elle évite le tour de passe-passe client/serveur.

La syntaxe de base est COPY (SELECT * FROM users) TO '/tmp/users.csv' WITH (FORMAT CSV, HEADER). Le fichier est écrit côté serveur, ce qui suppose un accès au système de fichiers de la base. Pour exporter depuis un client distant, on utilise plutôt \copy dans psql, qui exécute la même logique mais écrit sur la machine cliente.

COPY accepte un délimiteur personnalisé, des guillemets, un encodage et un format alternatif (TEXT, BINARY). Pour des exports massifs, c'est le bon choix : sur des tables de plusieurs millions de lignes, il reste linéaire en mémoire serveur tant que le SELECT lui-même n'agrège pas tout en RAM.

Exporter en JSON avec row_to_json

PostgreSQL gère le JSON nativement depuis la version 9.2. Pour un export JSON, deux approches dominent. La première utilise row_to_json ou json_agg directement en SQL, ce qui donne un fichier JSON valide en une commande.

Exemple type : COPY (SELECT json_agg(row_to_json(t)) FROM users t) TO '/tmp/users.json'. Cette commande produit un tableau JSON unique. Pour de très grosses tables, il vaut mieux éviter json_agg qui matérialise tout en mémoire serveur. À la place, on écrit du JSONL (un objet par ligne) avec COPY (SELECT row_to_json(t) FROM users t) TO '/tmp/users.jsonl', format que la plupart des pipelines analytiques savent lire.

La seconde approche combine psql et jq pour post-traiter une sortie textuelle. C'est utile quand on veut filtrer ou remodeler les enregistrements côté client, mais moins performant que les fonctions JSON natives.

Exporter en Parquet avec pg_parquet ou DuckDB

Parquet est un format colonne compressé, conçu pour l'analytique. Il n'est pas supporté nativement par PostgreSQL. Deux solutions existent. La première est l'extension pg_parquet (maintenue par Crunchy Data), qui ajoute une syntaxe COPY ... TO '...' (FORMAT PARQUET) directement dans le moteur. Elle exige des privilèges d'installation sur la base.

La seconde solution est DuckDB. On l'utilise comme moteur intermédiaire : DuckDB se connecte à PostgreSQL via son extension postgres_scanner, lit la table à distance et écrit le Parquet localement avec COPY (SELECT * FROM pg.users) TO 'users.parquet' (FORMAT PARQUET). Pas besoin de modifier la base source. C'est l'approche la plus flexible quand on n'a pas la main sur PostgreSQL.

Parquet compresse fortement les colonnes répétitives (typiquement 5 à 10x moins de volume qu'un CSV équivalent) et conserve les types. C'est le format de référence pour l'archivage analytique ou le chargement dans un data warehouse.

Quel format pour quel usage

CSV reste la lingua franca des échanges tabulaires. Excel, Sheets, R, Pandas, tous les ETL classiques le lisent. Il ne gère pas les types ni les structures imbriquées, mais sa simplicité reste un atout pour partager un extrait avec un collègue non-technique ou alimenter un tableur.

JSON est indiqué quand les données contiennent du JSONB, des objets imbriqués ou des champs de longueur variable. Il préserve la structure, au prix d'un volume sensiblement plus élevé. Le JSONL (un objet par ligne) est préférable au JSON-array dès qu'on dépasse quelques centaines de milliers de lignes.

Parquet s'impose pour l'analytique : volumes importants, requêtes colonnaires, chargement dans BigQuery, Snowflake, Athena, DuckDB. Il conserve les types numériques, dates et booléens, et reste lisible des années plus tard sans dépendance à un encodage local.

Exporter depuis un client GUI

Les commandes natives sont efficaces mais demandent un accès shell et la connaissance des options. Pour un workflow régulier, un client GUI évite les allers-retours. DBeaver propose un assistant d'export vers CSV, JSON, XML et SQL. DataGrip fait de même. pgAdmin reste limité au CSV et au format binaire PostgreSQL.

QoreDB exporte vers CSV, JSON, SQL, HTML, XLSX et Parquet depuis n'importe quel résultat de requête. L'export passe par un pipeline de streaming côté Rust : la requête est lue ligne par ligne via curseur, sérialisée à la volée par un writer dédié à chaque format, puis écrite sur disque. La mémoire reste bornée même sur des exports de plusieurs millions de lignes.

Le writer Parquet utilise les crates Arrow et Parquet officielles, avec une taille de row group de 10 000 lignes et un mapping de types automatique (int, float, bool, binary, string). Les exports longs passent par le Background Job Manager : l'utilisateur peut lancer plusieurs exports en parallèle, suivre leur progression et continuer à travailler.

Choisir son approche selon le contexte

Pour un export ponctuel et scriptable, COPY en ligne de commande est imbattable. Pour un workflow récurrent où l'on veut filtrer un résultat, prévisualiser et exporter dans plusieurs formats, un client GUI fait gagner du temps. Pour du Parquet sans installer d'extension côté serveur, DuckDB en local est la meilleure passerelle.

Le choix du format se ramène à trois questions : qui consomme le fichier, quel volume, quelle durée de vie. CSV pour les humains et les tableurs, JSON pour les structures complexes, Parquet pour l'analytique de long terme. Avec les outils actuels, produire les trois depuis PostgreSQL est une question de minutes, pas d'heures.