Экспорт данных из SQLite: CSV, JSON и SQL-дамп

Экспорт данных в SQLite — это работа shell, а не SQL-команды

В SQLite нет ни COPY ... TO, ни SELECT INTO OUTFILE, как в Postgres или MySQL. Экспорт данных живёт в командной оболочке sqlite3 и управляется dot-командами: .mode, .headers, .output, .dump. Освоив эти четыре команды, вы сможете выгрузить из любой базы данные в CSV, JSON, обычный текст или полноценный SQL-дамп.

Принцип простой: вы говорите оболочке, как форматировать результат (.mode), нужно ли выводить названия колонок (.headers) и куда направить вывод (.output). Затем выполняете запрос — и его результат улетает прямо в файл.

Давайте поднимем небольшую базу для экспериментов:

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;

Три строки, четыре столбца. Эти данные мы и будем выгружать в разных форматах.

Экспорт sqlite в CSV: .mode csv с заголовками

CSV — самый ходовой формат для выгрузки данных: его понимают и таблицы Excel, и data-пайплайны, и почти любые другие инструменты. Прямо в оболочке sqlite3 делаем так:

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

Что здесь произошло:

• .mode csv форматирует каждую строку как значения через запятую, экранируя поля с запятыми, кавычками или переносами строк.
• .headers on добавляет первую строку с именами столбцов. Без этой опции в CSV не будет заголовка — а это, как правило, не то, что нужно.
• .output users.csv перенаправляет результат в файл. С этого момента вывод запросов идёт в файл, а не на экран.
• SELECT отрабатывает и молча пишет данные в файл.
• .output stdout возвращает вывод обратно в терминал, чтобы увидеть результаты следующего запроса.

Получившийся файл:

id,name,email,signup_date
1,"Ада Лавлейс",ada@example.com,2025-01-15
2,"Борис Джонсон",boris@example.com,2025-02-03
3,"Кармен Диас",carmen@example.com,2025-03-22

Можно выгружать результат любого запроса, а не только целые таблицы — отфильтровать, сджойнить, посчитать агрегаты, а потом перенаправить вывод:

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

Однострочник прямо из терминала

Заходить в интерактивную оболочку вовсе не обязательно. Точечные команды и SQL можно передать в sqlite3 через пайп прямо из терминала ОС:

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

Это именно то, что нужно для скриптов и cron-задач — повторяемо и без ручного ввода. .output живёт только в рамках текущей сессии, так что состояние никуда не утекает.

JSON: .mode json

Если выгрузка идёт в веб-приложение или в инструмент, который ест JSON, режим .mode json отдаёт массив объектов — по одному на строку:

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"}]

В JSON заголовки и так присутствуют неявно — это сами ключи, поэтому .headers тут не нужен. Если хочется нестандартной структуры — вложенных объектов или переименованных полей — собирайте её прямо в запросе через 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;

Так вы получите построчные JSON-строки с полным контролем над структурой. А если обернуть всё это в json_group_array(), можно собрать весь результат в один JSON-документ.

Полный SQL-дамп базы: .dump

.dump стоит особняком от CSV и JSON — это совсем другой зверь. На выходе получается .sql-файл со схемой и данными в виде команд CREATE TABLE и INSERT, то есть всё необходимое, чтобы поднять базу с нуля:

sqlite3 mydb.sqlite .dump > backup.sql

A snippet of what comes out:

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;

Восстановление — зеркальная операция: скармливаем файл обратно в свежую базу:

Human Translation Patterns You are a native Russian speaker rewriting programming-tutorial prose as if it were originally authored in Russian by a human tech writer who teaches the sqlite programming language. You are NOT translating word-for-word. You are producing humanized, SEO-friendly native copy.

Humanization (#1 priority):

• The output must read like it was written by a real native speaker for a tech audience in that language. A native reader should not be able to tell it came from English.
• Reshape sentences freely: split long sentences, merge short ones, reorder clauses, swap idioms — whatever makes the prose sound natural in the target language.
• Use the terminology native programmers in that language actually use (from local dev blogs, YouTube, community forums). Avoid literal textbook calques of English jargon unless that calque is genuinely what locals say.
• Match the source's friendly, concrete, slightly informal register. Keep the warmth — don't make it sound like a formal manual.
• When in doubt between 'faithful to English structure' and 'sounds natural', always pick natural.

SEO awareness:

• Headings and the first sentence of each section should use the highest-intent locale-native search phrasing for the concept being taught (but still read naturally — no keyword stuffing).
• Use the same concept term consistently throughout the doc so it reinforces relevance for that keyword.

Formatting rules — STRICT (breaking these breaks the rendered page):

• Return only the translated markdown. No preamble, no outer code fences wrapping the whole thing, no commentary.
• Preserve markdown syntax exactly: headings (##, ###), lists, bold/italic, links, inline code.
• Preserve ALL leading AND trailing whitespace and blank lines exactly. If the input ends with \n\n (blank line), your output MUST end with \n\n. If it starts with \n, your output must start with \n. This is critical — code fences immediately follow these segments and the blank lines keep markdown valid.
• Inside inline backticks: keep identifiers, function/method names, keywords, and API names in English. BUT if a backtick wraps a string literal value that a code block above or below prints out, match the translated form — e.g. if the code prints "cargando...", prose references must say cargando..., not loading.... String-literal values in prose must match the code they describe.
• Internal links like /docs/python/loops stay as-is; the router handles locale prefixing.
• Avoid directional words ("on the left/right") — the site supports RTL languages. Prefer "before/after" or describe by meaning.

SEO keyword hints for this doc (use these native-language terms naturally in headings and opening sentences where they fit — do NOT stuff them):

• экспорт данных sqlite
• sqlite выгрузка в csv
• sqlite3 export csv
• выгрузить таблицу sqlite
• .dump sqlite
• sqlite дамп базы данных
• sqlite export to json
• .mode csv sqlite
• sqlite бэкап таблицы
• csv с заголовками sqlite

sqlite3 restored.sqlite < backup.sql

.dump — это правильный инструмент для бэкапов, снапшотов тестовых данных под систему контроля версий и переноса базы между машинами. Команда сохраняет всё: индексы, триггеры, представления — словом, всю схему целиком.

Дамп отдельной таблицы

Чтобы ограничить вывод, передайте .dump имя таблицы (или шаблон):

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

Так выгружается схема и данные только таблицы users. Удобно, когда надо перетащить одну таблицу в другую базу, не таща за собой всё остальное. Поддерживается и шаблон: .dump 'log_%' выгрузит все таблицы, имя которых начинается на log_.

Только схема, без данных

Иногда нужна именно структура — без строк. Например, для документации, чистого dev-окружения или чтобы сравнить схемы разных баз. Команда .schema выводит только CREATE-инструкции:

sqlite3 mydb.sqlite .schema > schema.sql

Если указать имя таблицы, получите дамп только её одной:

Human Created Document. Human: ### Saving Data to a File

Use the .output command to redirect output to a file:

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

На выходе вы получаете чистый SQL — CREATE TABLE, CREATE INDEX, CREATE TRIGGER, — который можно сразу выполнить на пустой базе.

Другие полезные режимы

У .mode есть варианты не только для CSV и JSON. Вот несколько, о которых стоит знать:

.mode column        -- выровненные столбцы, удобно читать в терминале
.mode markdown      -- разделение через "|", таблицы в стиле GitHub
.mode html          -- вывод в виде HTML <table>
.mode tabs          -- значения, разделённые табуляцией (TSV)
.mode insert users  -- генерирует INSERT-выражения для указанной таблицы
.mode quote         -- значения в SQL-кавычках, удобно для просмотра

.mode markdown отлично выручает, когда нужно вставить результаты запроса в README или в описание пул-реквеста. А .mode insert <table> — быстрый способ нагенерить тестовые данные: выполняешь SELECT, забираешь готовые INSERT-ы и кидаешь их в файл с фикстурами.

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

Несколько практических замечаний

• .output stdout (или просто .output без аргументов) возвращает вывод в терминал. Если забыть про это, результаты следующего запроса молча уйдут в файл.
• При экспорте в CSV типы данных не сохраняются. В файле всё превращается в текст, и при обратном импорте нужна целевая схема, чтобы правильно его интерпретировать. Если важно перенести данные в другую базу SQLite без потерь — используйте .dump.
• Большие выгрузки идут потоково. .output пишет строки по мере их получения, поэтому таблицы, превышающие объём оперативной памяти, выгружаются без проблем.
• Для горячего бэкапа работающей базы .dump тоже подойдёт, но специальная команда .backup (её мы разберём дальше по курсу) работает быстрее и безопаснее, потому что использует встроенный SQLite Online Backup API.

Дальше: чтение данных

Теперь у вас есть полная картина по записи данных — INSERT, UPDATE, DELETE, UPSERT, RETURNING, импорт из CSV и обратный экспорт. Дальше — вторая половина работы с базой: эффективное чтение данных. Большую часть времени вы будете проводить именно за SELECT-запросами, и им посвящена следующая страница.