Что такое миграция базы данных — это git для схемы, а не перенос данных

Слово «миграция» сбивает с толку. Кажется, что это перенос данных — с одного сервера на другой, из старой базы в новую. Почти всегда это про другое.

Миграция — это изменение структуры базы: добавил колонку, завёл новую таблицу, переименовал поле. И записывается оно так, чтобы его можно было повторить у себя, у напарника и на проде — одинаково. По сути это коммит, только не для кода, а для схемы.

Что такое миграция на самом деле

Миграция — это один файл с инструкцией «как поменять структуру базы». Внутри команды вроде «добавь таблицу заметки», «добавь колонку avatar_url», «сделай почту уникальной».

База помнит список уже применённых миграций. Поэтому она всегда знает, на каком «шаге» находится сейчас.

Данные при этом обычно не трогаются. Меняется форма, в которую они складываются, — не содержимое.

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

Почему нельзя просто поменять таблицу руками

Можно. Один раз, у себя. Проблема начинается на втором компьютере.

Ты добавил колонку в панели у себя — приложение заработало. Напарник скачал твой код, запустил — падает: у него в базе такой колонки нет. На проде — та же история. Структура кода и структура базы разъехались, и никто не помнит, что именно ты крутил руками три недели назад.

Миграция чинит это так же, как git чинит вопрос «а что мы вообще поменяли»: изменение записано в файл, файл лежит в репозитории, применяется одной командой у всех одинаково.

Как это работает: шаг вперёд и шаг назад

У аккуратной миграции две стороны.

• Up (вперёд) — что сделать: добавить таблицу, колонку, связь.
• Down (назад) — как это откатить: удалить то, что добавил.

Зачем down? Чтобы можно было отступить. Выкатил миграцию, поймал баг — команда «откат», и структура вернулась на шаг назад. Без down ты как в игре без сохранений: вперёд можно, назад — только собирать заново.

Порядок тоже важен. Миграции применяются по очереди, как коммиты в git: пятая не встанет раньше четвёртой. Поэтому у каждой есть номер или дата — это её место в очереди. Маленький шаг, у которого есть порядок и который можно отмотать.

Почему это важно тебе — даже если ты один

«Я один, мне не с кем синхронизировать базу» — частая мысль. Но напарник у тебя есть всегда: это ты сам через месяц и твой прод.

Три причины держать миграции с самого начала:

• Прод — это второй компьютер. У тебя на ноуте одна база, в облаке — другая. Миграция — единственный честный способ докатить изменение туда, ничего не забыв.
• ИИ пишет тебе схему. Просишь агента «добавь таблицу для комментариев» — он генерит миграцию. Не сохранишь её в репозиторий — завтра не вспомнишь, что и когда поменялось.
• Откат спасает вечер. Плохое изменение схемы без миграции откатываешь руками и по памяти. С миграцией — одной командой.

Где ты встретишь миграции первым делом

Как только заведёшь базу через Supabase, Firebase или любой инструмент с ORM — миграции появятся сами. Многие сервисы генерят их за тебя: ты меняешь модель в коде, инструмент видит разницу и пишет миграцию. Тебе остаётся её просмотреть и применить.

Главное усвоить сразу: изменение схемы — это не «кликнул в интерфейсе», а файл, который едет в репозиторий вместе с кодом. Тогда база и код всегда рассказывают одну историю.

Миграция и бэкап — это одно и то же?

Нет. Бэкап — это копия данных на случай потери. Миграция — это изменение структуры, которое едет вперёд вместе с кодом. Бэкап отвечает на «как вернуть данные», миграция — на «как поменять форму базы одинаково у всех».

Нужны ли миграции для крошечного проекта?

Если база вообще есть — да, самые простые. Даже одна колонка, добавленная руками, однажды сломает прод, который про неё не знает. Миграция стоит пары минут и снимает целый класс «у меня работает, а в облаке нет».