Exporter une base SQLite : CSV, JSON et dump SQL

L'export, c'est le shell qui s'en charge, pas une instruction SQL

SQLite n'a pas de COPY ... TO ni de SELECT INTO OUTFILE comme Postgres ou MySQL. Pour exporter des données, tout se passe dans le shell en ligne de commande sqlite3, à coups de commandes pointées : .mode, .headers, .output, .dump. Une fois ces quatre commandes en poche, vous pouvez générer du CSV, du JSON, du texte brut ou un dump SQL complet depuis n'importe quelle base.

Le modèle mental est simple : on indique au shell comment formater les résultats (.mode), s'il faut inclure les noms de colonnes (.headers) et où envoyer la sortie (.output). Ensuite on lance une requête, et ses résultats atterrissent dans le fichier.

Préparons une petite base pour jouer avec tout ça :

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    email TEXT NOT NULL,
    signup_date TEXT NOT NULL
);

INSERT INTO users (name, email, signup_date) VALUES
    ('Ada Lovelace', 'ada@example.com', '2025-01-15'),
    ('Boris Johnson', 'boris@example.com', '2025-02-03'),
    ('Carmen Diaz', 'carmen@example.com', '2025-03-22');

SELECT * FROM users;

Trois lignes, quatre colonnes. On va exporter ça dans plusieurs formats.

Exporter en CSV : .mode csv avec en-têtes

Le CSV reste le format d'export le plus répandu — tableurs, pipelines de données et la plupart des outils savent le lire. Depuis le shell sqlite3 :

sqlite> .mode csv
sqlite> .headers on
sqlite> .output users.csv
sqlite> SELECT * FROM users;
sqlite> .output stdout

Ce qui vient de se passer :

• .mode csv formate chaque ligne au format CSV, en mettant entre guillemets les champs qui contiennent des virgules, des guillemets ou des sauts de ligne.
• .headers on ajoute une première ligne avec les noms des colonnes. Sans cette option, votre CSV n'aura pas d'en-tête — ce qui n'est généralement pas le résultat souhaité.
• .output users.csv redirige la sortie vers un fichier. À partir de ce moment-là, le résultat des requêtes part dans le fichier au lieu de s'afficher à l'écran.
• Le SELECT s'exécute et écrit dans le fichier, sans rien afficher.
• .output stdout rebascule la sortie vers le terminal, pour que vous puissiez voir le résultat de la requête suivante.

Voici le fichier obtenu :

id,name,email,signup_date
1,"Ada Lovelace",ada@example.com,2025-01-15
2,"Boris Johnson",boris@example.com,2025-02-03
3,"Carmen Diaz",carmen@example.com,2025-03-22

Vous pouvez exporter le résultat de n'importe quelle requête, pas seulement des tables entières — filtrez, faites des jointures, agrégez, puis redirigez la sortie :

sqlite> .output recent_users.csv
sqlite> SELECT name, email FROM users WHERE signup_date >= '2025-02-01';
sqlite> .output stdout

Une commande en ligne depuis le terminal

Pas besoin d'ouvrir le shell interactif. Vous pouvez envoyer directement les dot-commands et le SQL à sqlite3 depuis le terminal de votre système :

sqlite3 mydb.sqlite <<EOF
.headers on
.mode csv
.output users.csv
SELECT * FROM users;
EOF

C'est la forme à privilégier pour les scripts et les tâches cron — reproductible, sans saisie manuelle. Le .output reste local à la session, donc rien ne fuite ailleurs.

JSON : sqlite export json avec .mode json

Pour un export destiné à une appli web ou à un outil qui consomme du JSON, .mode json produit un tableau d'objets, à raison d'un objet par ligne :

sqlite> .mode json
sqlite> .output users.json
sqlite> SELECT * FROM users;
sqlite> .output stdout

The file:

[{"id":1,"name":"Ada Lovelace","email":"ada@example.com","signup_date":"2025-01-15"},
{"id":2,"name":"Boris Johnson","email":"boris@example.com","signup_date":"2025-02-03"},
{"id":3,"name":"Carmen Diaz","email":"carmen@example.com","signup_date":"2025-03-22"}]

En JSON, les en-têtes sont implicites (ce sont les clés), donc .headers n'a aucun effet ici. Si vous voulez une structure sur mesure — objets imbriqués, champs renommés — construis-la directement dans la requête avec json_object() :

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, email TEXT);
INSERT INTO users (name, email) VALUES
    ('Ada Lovelace',  'ada@example.com'),
    ('Boris Johnson', 'boris@example.com'),
    ('Carmen Diaz',   'carmen@example.com');

SELECT json_object(
    'id', id,
    'name', name,
    'contact', json_object('email', email)
) AS user_json
FROM users;

Vous obtenez ainsi des chaînes JSON ligne par ligne, avec un contrôle total sur la structure. Combine le tout avec json_group_array() pour regrouper le résultat complet en un seul document JSON.

Dump SQL complet : .dump

.dump joue dans une autre catégorie que CSV ou JSON. La commande génère un fichier .sql qui contient à la fois le schéma et toutes les données, sous forme d'instructions CREATE TABLE et INSERT — de quoi reconstruire la base depuis zéro :

sqlite3 mydb.sqlite .dump > backup.sql

Un aperçu de ce que ça donne :

PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    email TEXT NOT NULL,
    signup_date TEXT NOT NULL
);
INSERT INTO users VALUES(1,'Ada Lovelace','ada@example.com','2025-01-15');
INSERT INTO users VALUES(2,'Boris Johnson','boris@example.com','2025-02-03');
INSERT INTO users VALUES(3,'Carmen Diaz','carmen@example.com','2025-03-22');
COMMIT;

La restauration, c'est l'opération miroir : il suffit de réinjecter le fichier dans une nouvelle base de données :

sqlite3 restored.sqlite < backup.sql

.dump est l'outil parfait pour faire des sauvegardes, versionner des jeux de données de test ou migrer une base d'une machine à l'autre. Il conserve tout : index, triggers, vues — bref, l'intégralité du schéma.

Exporter une seule table avec .dump

.dump accepte un nom de table (ou un motif) pour cibler la sortie :

sqlite3 mydb.sqlite ".dump users" > users_only.sql

Cela exporte uniquement le schéma et les lignes de la table users. Pratique si vous voulez recopier une table dans une autre base sans embarquer le reste. Vous pouvez aussi filtrer par motif : .dump 'log_%' exporte toutes les tables dont le nom commence par log_.

Le schéma sans les données

Parfois, on veut juste la structure, sans les lignes — pour documenter le projet, monter un environnement de dev propre, ou comparer les schémas entre plusieurs bases. La commande .schema n'affiche que les instructions CREATE :

sqlite3 mydb.sqlite .schema > schema.sql

Associez-la à un nom de table pour n'en récupérer qu'une seule :

Human Tasks

sqlite3 mydb.sqlite ".schema users" > users_schema.sql

La sortie est du SQL pur — CREATE TABLE, CREATE INDEX, CREATE TRIGGER — prêt à être exécuté sur une base vide.

D'autres modes bien pratiques

.mode ne se limite pas à CSV et JSON. Voici quelques options qui valent le détour :

.mode column        -- colonnes alignées, agréable à lire dans le terminal
.mode markdown      -- séparé par des pipes, tableaux compatibles GitHub
.mode html          -- sortie HTML <table>
.mode tabs          -- valeurs séparées par des tabulations (TSV)
.mode insert users  -- émet des instructions INSERT pour la table nommée
.mode quote         -- valeurs entre guillemets SQL, utile pour l'inspection

.mode markdown est parfait pour coller le résultat d'une requête dans un README ou une pull request. Quant à .mode insert <table>, c'est une astuce rapide pour générer des données de seed : vous lancez un SELECT, vous récupérez les instructions INSERT et vous les collez dans un fichier de fixtures.

sqlite> .mode insert users
sqlite> .output seed.sql
sqlite> SELECT * FROM users WHERE signup_date >= '2025-02-01';
sqlite> .output stdout

Quelques remarques pratiques

• .output stdout (ou .output sans argument) rétablit la sortie vers le terminal. Si vous oubliez, les résultats de la requête suivante partiront silencieusement dans le fichier.
• L'export CSV ne conserve pas les types. Tout devient du texte dans le fichier, et pour le réimporter il faut un schéma cible qui sache l'interpréter. Si vous tenez à faire un aller-retour vers une autre base SQLite, utilisez plutôt .dump.
• Les gros exports sont streamés. .output écrit les lignes au fur et à mesure qu'elles sont produites : vous pouvez donc exporter des tables plus grosses que la RAM sans souci.
• Pour une sauvegarde à chaud d'une base en cours d'utilisation, .dump fonctionne, mais la commande dédiée .backup (abordée plus loin dans le cursus) est plus rapide et plus sûre, car elle s'appuie sur l'API de sauvegarde en ligne de SQLite.

La suite : interroger les données

Vous avez maintenant une vue complète sur l'écriture des données — INSERT, UPDATE, DELETE, UPSERT, RETURNING, l'import depuis CSV et l'export en sens inverse. Place à l'autre moitié du travail avec une base de données : lire les données efficacement. C'est dans l'instruction SELECT que vous passerez le plus clair de votre temps, et c'est justement le sujet de la page suivante.