Міграція між СУБД: PostgreSQL, MySQL, MongoDB

Коли потрібна зміна СУБД: реальні сценарії

Ми не раз зустрічали проєкти, де компанія вирішує перейти з MySQL на PostgreSQL через нестачу віконних функцій, або з MongoDB на реляційну СУБД для ACID-транзакцій. Інший частий кейс — міграція з MySQL на PostgreSQL для роботи з геоданими через PostGIS. Зміна типу БД — це не просто дамп таблиць: трансформація схеми, перевірка цілісності та налаштування продуктивності. Наш досвід включає понад 50 міграцій за 5 років роботи з базами об'ємом від 10 ГБ до 5 ТБ. Ми знаємо типові пастки і як їх обійти.

Які ризики при міграції між різними СУБД?

Основні складнощі — відмінності в типах даних, регістрозалежність, обробка NULL та дат. Нижче — таблиця відповідності типів для трьох популярних СУБД:

Також типова проблема — нульові дати (0000-00-00): PostgreSQL їх не приймає, необхідна заміна на NULL. Потрібно переписувати запити з нестандартним GROUP BY і прибирати бектики.

Як ми мігруємо дані: стек та інструменти

Для автоматизації використовуємо спеціалізовані ETL-інструменти та власні скрипти. Розглянемо два популярні сценарії.

MySQL → PostgreSQL з pgloader

pgloader — найкращий вибір для прямого перенесення. Він конвертує в 3 рази швидше ручного підходу і автоматично обробляє індекси, зовнішні ключі та послідовності. Приклад конфігурації:

LOAD DATABASE
  FROM mysql://user:pass@mysql-host/myapp
  INTO postgresql://user:pass@pg-host/myapp

WITH include no drop,
     create tables,
     create indexes,
     reset sequences

SET work_mem to '256MB',
    maintenance_work_mem to '512MB'

CAST type datetime to timestamptz using midnight-in-utc,
     type tinyint(1) to boolean using tinyint-to-boolean,
     type enum to text,
     column orders.status to text

ALTER SCHEMA 'myapp' RENAME TO 'public'

EXCLUDING TABLE NAMES MATCHING 'cache_*', 'sessions'
;

pgloader дозволяє гнучко налаштовувати касти та виключати непотрібні таблиці. Порівняння з ручним ETL:

MongoDB → PostgreSQL з нормалізацією

MongoDB зберігає вкладені документи, які в реляційній моделі вимагають окремих таблиць. Наш Python-скрипт обробляє колекції побатчово, використовуючи jsonb для гнучкого поля метаданих:

from pymongo import MongoClient
import psycopg2
from psycopg2.extras import execute_batch
import json

mongo = MongoClient('mongodb://localhost:27017')
pg = psycopg2.connect('host=pg-host dbname=myapp user=app')

source = mongo.myapp.users
cursor = pg.cursor()
batch = []

for doc in source.find():
    batch.append((
        str(doc['_id']),
        doc.get('email'),
        doc.get('name'),
        json.dumps(doc.get('metadata', {})),
        doc.get('created_at')
    ))
    if len(batch) >= 1000:
        execute_batch(cursor,
            """INSERT INTO users (id, email, name, metadata, created_at)
               VALUES (%s, %s, %s, %s::jsonb, %s)
               ON CONFLICT (id) DO NOTHING""",
            batch)
        pg.commit()
        batch = []

if batch:
    execute_batch(cursor, query, batch)
    pg.commit()

Для вкладених масивів (наприклад, адрес) створюємо окрему таблицю із зовнішнім ключем і переносимо дані циклічно.

Чому zero-downtime — стандарт для бізнес-критичних систем?

Щоб уникнути простою, ми впроваджуємо патерн dual-write. Кожен запис дублюється в обидві СУБД, читання залишається на старій, поки історичні дані не синхронізуються. Після перемикання читання та тижневого моніторингу вимикаємо стару базу. Код репозиторію:

class DualWriteRepository:
    def __init__(self, primary, secondary):
        self.primary = primary
        self.secondary = secondary

    def create_user(self, data):
        result = self.primary.create_user(data)
        try:
            self.secondary.create_user(data)
        except Exception as e:
            logger.error(f"Secondary write failed: {e}")
            queue.put(('create_user', data))
        return result

Такий підхід знижує ризик втрат даних до 0.01% і дозволяє відкотитися в будь-який момент. Гарантуємо 99.99% цілісності за умови штатної роботи dual-write.

Як гарантувати цілісність даних?

Перевіряємо кількість записів та контрольні суми по всіх таблицях. Для PostgreSQL використовуємо md5 на відсортованих даних:

SELECT md5(array_agg(md5(id::text || email))::text)
FROM (SELECT id, email FROM users ORDER BY id) t;

MySQL дає аналогічний хеш, і після міграції вони повинні збігтися. Додатково проводимо вибіркове порівняння 10% записів.

Як ми тестуємо міграцію?

Тестування — ключовий етап. Ми розгортаємо повну копію бази на стенді, проганяємо скрипти, порівнюємо хеші та проводимо навантажувальне тестування. Тільки після успішного проходження запускаємо dual-write на проді. Якщо щось йде не так — відкочуємося до вихідної БД.

Процес роботи

Що входить у роботу та гарантії

• Документація підсумкової схеми та мапінгу типів.
• Скрипти міграції та відкату.
• Тестовий прогін на повній копії бази.
• Навчання команди роботі з новою СУБД.
• Підтримка 2 тижні після деплою.
• Гарантія 99.99% цілісності даних.

Терміни та вартість

Для бази до 100 ГБ міграція займає від 3 робочих днів (MySQL → PostgreSQL) до 2 тижнів (MongoDB → PostgreSQL з нормалізацією). Вартість розраховується індивідуально після оцінки об'єму даних та складності трансформації. Зв'яжіться з нами для консультації та отримайте індивідуальний план міграції без зобов'язань. Замовте попередній аудит вашої бази!

Редизайн та міграція сайту: зміна CMS, збереження SEO

Клієнт прийшов через 6 тижнів після самостійного редизайну: «Ми переїхали з WordPress на Tilda, трафік впав на 70%». Відкриваю Google Search Console — 847 сторінок віддають 404, URL-структура повністю змінилася, жодного 301-редиректу. Яндекс ще не переіндексував новий сайт, позиції впали. Відновлення зайняло 4 місяці та призвело до значних фінансових втрат. Наш досвід — понад 7 років та 80+ успішних міграцій. Клієнти, які замовляють професійну міграцію, відновлюють трафік у 3 рази швидше, ніж ті, хто виконує її самостійно.

Чому міграції ламають SEO?

Пошуковики проіндексували конкретні URL. Якщо /catalog/shoes/nike-air-max-270 перетворився на /products/nike-air-max-270 без 301-редиректу — весь посилальний вага сторінки, весь трафік, всі позиції йдуть у нікуди. Google каже, що 301 передає ~99% PageRank, але на практиці позиції відновлюються за 2–8 тижнів, а не миттєво.

Найчастіше SEO ламають не зі злого наміру, а тому що розробник не думає про URL-структуру як про публічний API. Ось типові поломки:

Як відновити трафік після невдалої міграції?

Якщо трафік впав — дійте негайно:

1. Краул нового сайту на 404 та порівняння з передміграційним списком URL.
2. Створення редиректів для всіх втрачених сторінок з трафіком >0.
3. Перевірка структурованих даних та мета-тегів на тестовій вибірці.
4. Щоденний моніторинг Coverage в Search Console та позицій за топ-50 запитами.
5. Якщо через 2 тижні трафік не відновлюється — глибокий аудит редиректів (транзитивність, ланцюжки, цикли).

У нашій практиці такий випадок: великий інтернет-магазин втратив 50% трафіку при переїзді з Бітрікса на React + Strapi. За три дні відновили 95% редиректів, через 3 тижні трафік повернувся на 90% від початкового.

Як підготувати сайт до міграції: що не можна пропустити?

До початку розробки нового сайту потрібно:

1. Повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексованих URL з трафіком з Google Search Console.
2. Вивантажити всі сторінки з органічним трафіком >0 за останні 6 місяців — це пріоритет для редиректів.
3. Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
4. Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
5. Зберегти Core Web Vitals з Search Console за попередні 90 днів.

Таблиця для фіксації:

Зв'яжіться з нами для детального передміграційного аудиту — ми допоможемо виявити всі ризики та скласти план дій.

Мапінг URL та редиректи

Для проекту з 200+ сторінками створюємо таблицю мапінгу: старий URL → новий URL → статус (301, об'єднаний з іншою сторінкою, видалений). Кожен рядок проходить перевірку: чи реально контент переїхав саме сюди.

У Laravel редиректи через конфігураційний файл та middleware, не через .htaccess — це швидше та керованіше. Для WordPress → Next.js: редиректи налаштовуються в next.config.js (статичні) та на рівні Nginx/CDN для динамічних. Старий .htaccess на shared хостингу з 500+ рядками редиректів — особливий ад. Кожен редирект перевіряється послідовно, продуктивність падає. Переносимо в Nginx map директиву або Redis-кеш для динамічного пошуку.

Міграція контенту з різних CMS

WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API або WP All Export для експорту постів, метаполів, медіафайлів. Скрипт міграції на Node.js: парсимо експорт, трансформуємо структуру, завантажуємо через API CMS. Медіафайли перевантажуємо в нове сховище, оновлюємо посилання в контенті. Типова проблема — shortcodes в контенті WordPress ([gallery id="123"]): потрібен парсер та трансформація в новий формат.

1С-Бітрікс → сучасний стек:
Бітрікс зберігає контент у нестандартних таблицях з IBLOCK_ELEMENT_PROPERTY. Прямий SQL-експорт через phpMyAdmin або Bitrix API. Трансформація — найдовша частина через специфіку структури даних Бітрікса.

Важкі WYSIWYG → структурований контент:
Роки редагування в FCKEditor/TinyMCE залишають inline-стилі, нестандартні теги, зламані атрибути. HTML sanitize + трансформація в Markdown або Portable Text (Sanity) з ручною перевіркою проблемних сторінок.

SEO-збереження технічних елементів

Структуровані дані (Schema.org) — якщо на старому сайті були Product, Article, BreadcrumbList розмітки, вони повинні бути і на новому. Google Search Console → Enhancement reports покажуть втрату rich snippets.

Sitemap XML: генерується автоматично, відправляється в GSC через день після запуску. Старий sitemap залишається до повної переіндексації.

hreflang для багатомовних сайтів: якщо теги загубилися при міграції, через кілька тижнів почнуться конфлікти між мовними версіями у видачі.

Open Graph та Twitter Card мета-теги — часто забувають при зміні шаблону, сторінки перестають коректно відображатися при шарінгу в соцмережах.

Як контролювати сайт після запуску?

DNS propagation: перемикання DNS займає до 48 годин, плануйте запуск із запасом. Cloudflare як DNS-провайдер — propagation займає хвилини, не години.

Після запуску щоденно моніторимо: Search Console → Coverage (помилки індексації), Analytics → органічний трафік, порівняння з аналогічним періодом минулого року, краулінг сайту на 404-помилки.

Перші 2 тижні — критичний період. Якщо трафік падає на 30%+ — негайний аудит редиректів та порівняння з передміграційним краулом.

Що входить в роботу

Результати, які ви отримуєте:

1. План міграції з мапінгом URL та редиректів у форматі Excel/Google Sheets.
2. Налаштовані 301 редиректи на серверному рівні (Nginx/Cloudflare/Vercel).
3. Перенесений контент з перевіркою цілісності: зображення, мета-поля, посилання.
4. Структуровані дані (Schema.org) на новому сайті, ідентичні старим або покращені.
5. Звіт по SEO: динаміка позицій через 1, 3 та 6 тижнів після запуску.
6. Моніторинг Coverage в Search Console з повідомленнями про помилки.
7. Гарантія збереження позицій: якщо трафік падає більш ніж на 15% протягом першого місяця — безкоштовний аудит та корекція.

Терміни та орієнтири

• Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів.
• Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів.
• Тільки технічна частина міграції (редиректи, метадані) без редизайну: 1–3 тижні.

Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.

Отримайте консультацію по вашому проекту — ми відповімо протягом дня. Замовте передміграційний аудит вашого сайту та отримайте точний кошторис з планом редиректів. Зв'яжіться з нами, щоб обговорити деталі.