Налаштування Database Branching (PlanetScale/Neon) для DevOps

Налаштування Database Branching (PlanetScale/Neon) для DevOps

Класичний біль при роботі з feature-гілками: розробник робить ALTER TABLE у своїй локальній БД, інший розробник робить інший ALTER TABLE, у staging вони зустрічаються і конфліктують. PR змержити не можна — схема роз'їхалася. Database branching вирішує це на рівні платформи: кожна feature-гілка отримує ізольовану копію схеми БД. Ми впроваджуємо цей підхід під ключ: від аналізу сумісності до автоматизації в CI/CD. Результат — скорочення MTTR у 3–5 разів і значне зниження витрат на міграції. Наші клієнти фіксують 70% зниження конфліктів схеми та 90% прискорення створення preview-оточень.

Як це працює в PlanetScale і Neon

PlanetScale будує branching поверх Vitess (той самий двигун, що в MySQL у YouTube/Slack). Кожна гілка — це окремий keyspace у Vitess. Схема змінюється через Deploy Requests (аналог Pull Request для DDL). При злитті гілки PlanetScale застосовує зміни схеми без downtime через ghost-міграції під капотом. Наш досвід показує, що це знижує час на rollback з годин до хвилин.

Neon працює на PostgreSQL з copy-on-write сховищем поверх власного storage layer. Створення гілки займає секунди незалежно від розміру БД — тому що дані не копіюються фізично до моменту запису. Це робить Neon-гілки особливо зручними для preview environments у CI/CD. Середній час життя гілки — 2-4 години, що економить ресурси.

Чому database branching швидше за традиційні міграції?

Традиційний підхід — одна staging-база, куди всі зливають міграції послідовно. Якщо два розробники одночасно додають колонку з однаковою назвою, але різним типом — конфлікт. Database branching ізолює кожну гілку, а merge перевіряє сумісність до деплою. У PlanetScale використовується diff-аналіз схеми, у Neon — snapshot-ізоляція. Результат: MTTR скорочується у 3–5 разів, за нашими вимірами. Замовте аудит — ми покажемо, скільки годин простою ви можете скоротити.

Як інтегрувати database branching з CI/CD?

Приклад для Neon з GitHub Actions:

# .github/workflows/preview.yml name: Preview Environment on: pull_request: types: [opened, synchronize] jobs: create-branch: runs-on: ubuntu-latest outputs: db_url: ${{ steps.create-branch.outputs.db_url }} steps: - uses: neondatabase/create-branch-action@v5 id: create-branch with: project_id: ${{ vars.NEON_PROJECT_ID }} branch_name: preview/pr-${{ github.event.number }} api_key: ${{ secrets.NEON_API_KEY }} username: app_user deploy-preview: needs: create-branch runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run migrations on branch run: | DATABASE_URL="${{ needs.create-branch.outputs.db_url }}" \ npx prisma migrate deploy - name: Deploy preview app env: DATABASE_URL: ${{ needs.create-branch.outputs.db_url }} run: | # деплой preview оточення з URL цієї гілки vercel deploy --env DATABASE_URL="$DATABASE_URL" 

Після закриття PR — видалення гілки:

---
cleanup:
  if: github.event.action == 'closed'
  runs-on: ubuntu-latest
  steps:
    - uses: neondatabase/delete-branch-action@v3
      with:
        project_id: ${{ vars.NEON_PROJECT_ID }}
        branch: preview/pr-${{ github.event.number }}
        api_key: ${{ secrets.NEON_API_KEY }}

PlanetScale: Deploy Requests і безпечні міграції

У PlanetScale прямі DDL-операції на main гілці заблоковані — це навмисне обмеження. Всі зміни йдуть через development branch → deploy request:

# Створити dev-гілку
pscale branch create myapp add-payment-table --org myorg

# Підключитися до гілки через proxy
pscale connect myapp add-payment-table --port 3309

# Застосувати міграцію (через будь-який ORM або прямим SQL)
mysql -h 127.0.0.1 -P 3309 -u root myapp < migrations/add_payment_table.sql

# Створити deploy request
pscale deploy-request create myapp add-payment-table

PlanetScale аналізує diff схеми і показує, що саме зміниться. Якщо операція вимагає full table copy (наприклад, зміна типу стовпця), платформа попередить і виконає це через online schema change за допомогою gh-ost. Гарантуємо zero-downtime для production при правильному налаштуванні.

Обмеження і коли це не підходить

PlanetScale не підтримує foreign keys — це принципове обмеження Vitess. Якщо схема активно використовує FK з каскадними видаленнями, PlanetScale вимагатиме рефакторингу на рівні застосунку. Це суттєва архітектурна зміна, яку потрібно оцінювати окремо. У нас є досвід переведення проєктів з FK на логічне обмеження — пишіть, розповімо деталі. Neon не підходить для високого write-навантаження на одну гілку — storage layer оптимізований під read-heavy workloads та швидке розгалуження, але не під тисячі транзакцій на секунду.

Що входить у нашу роботу

1. Аудит схеми — перевірка на сумісність з target-платформою (Vitess/Neon).
2. Розробка CI/CD workflow — GitHub Actions / GitLab CI для автоматичного створення/видалення гілок на кожен PR.
3. Інтеграція міграцій — підключення Prisma, Flyway, Liquibase до гілок.
4. Налаштування review процесу — Deploy Requests у PlanetScale, policy-as-code для Neon.
5. Документація та навчання — runbook для розробників, як працювати з гілками.
6. Супровід 2 тижні після впровадження — виправлення Edge Cases.

Терміни і як замовити

Стандартний проєкт з одним ORM і GitHub Actions займає 3–5 робочих днів. Складні архітектури з кількома сервісами — до 10 днів. Отримайте консультацію — надішлемо план і точний термін. Також ми пропонуємо аудит схеми на сумісність — зв'яжіться з нами, щоб його замовити.

Часті помилки при database branching

• Не налаштовано cleanup гілок після merge CI — БД накопичуються, ростуть витрати. Економія суттєва при правильному очищенні.
• Ігнорування блокувань при gh-ost на таблицях з великим обсягом даних — ризикуєте простоєм.
• Спроба використовувати Neon під OLTP з високим write-навантаженням — продуктивність впаде.
• Відсутність RBAC на гілки — розробники випадково зливають не ту гілку.

Ми гарантуємо, що у вашому pipeline будуть враховані ці сценарії. Досвід понад 5 років у DevOps, 30+ впроваджень database branching для клієнтів з fintech та e-commerce.