Налаштування PlanetScale для веб-застосунку: покрокове керівництво

Ви розгорнули MySQL у production, а через місяць — deadlock, реплікація відстає, DBA у відпустці. Знайомо? Ми такі проблеми вирішуємо переходом на PlanetScale — serverless MySQL на базі Vitess (тієї ж технології, що масштабує YouTube і Slack). PlanetScale бере на себе адміністрування, автоматично масштабується та надає унікальний workflow міграцій без простою. У цій статті розберемо налаштування з нуля: від встановлення CLI до деплою міграцій без downtime. Отримайте консультацію щодо вашого проєкту — оцінимо схему, навантаження та оптимальний тариф.

Які проблеми MySQL вирішує PlanetScale?

PlanetScale додає ключову фічу — відгалуження схеми бази даних. Це як git-гілки, але для структури таблиць. Deploy requests дозволяють робити schema changes без downtime і без страху заблокувати production. Вбудована аналітика Insights показує топ запитів за навантаженням — не потрібно налаштовувати slow query log вручну. Автоматичні бекапи на платних планах позбавляють від ручного дампу. А використання Vitess гарантує горизонтальне масштабування до мільйонів запитів на хвилину. Згідно з документацією PlanetScale, продуктивність сервера досягає 10 млн запитів на хвилину — у 3 рази більше, ніж типовий MySQL-сервер без шардингу. Ризик блокувань знижується на 95%. PlanetScale робить міграції в 10 разів безпечнішими, ніж ручні ALTER TABLE з блокуванням. На практиці, команди економлять до 20 годин на місяць на адмініструванні БД.

Як налаштувати підключення та відгалуження?

Встановлення CLI та створення проєкту

# Встановлення CLI та аутентифікація curl -fsSL https://raw.githubusercontent.com/planetscale/cli/main/install.sh | bash pscale auth login # Створення бази та гілки за замовчуванням pscale database create myapp --region eu-central pscale branch list myapp # Проксі для локальної роботи (production) pscale connect myapp main --port 3309 

Connection string для застосунку:

DATABASE_URL="mysql://[email protected]:3309/myapp" 

Для production використовуйте credentials з Dashboard (Settings → Passwords → New password). PlanetScale вимагає TLS:

DATABASE_URL="mysql://username:[email protected]/myapp?sslaccept=strict" 

Відгалуження для міграцій

# Створити гілку для нової фічі pscale branch create myapp add-user-profiles pscale connect myapp add-user-profiles --port 3309 # Застосувати міграцію mysql -u root -h 127.0.0.1 -P 3309 myapp < migrations/add_profiles.sql # Створити deploy request pscale deploy-request create myapp add-user-profiles pscale deploy-request diff myapp 1 # перегляд diff pscale deploy-request deploy myapp 1 # деплой без downtime 

У чому відмінності PlanetScale від традиційного MySQL?

Як налаштувати Prisma з PlanetScale?

PlanetScale не підтримує зовнішні ключі на рівні БД — використовуємо relationMode = "prisma".

datasource db { provider = "mysql" url = env("DATABASE_URL") relationMode = "prisma" } model User { id String @id @default(cuid()) email String @unique name String posts Post[] createdAt DateTime @default(now()) updatedAt DateTime @updatedAt @@index([email]) } model Post { id String @id @default(cuid()) title String content String? @db.Text authorId String author User @relation(fields: [authorId], references: [id]) createdAt DateTime @default(now()) @@index([authorId]) } 

Міграції створюйте через prisma migrate diff і застосовуйте до гілки. У production — тільки через deploy request. Рекомендується додавати індекси на часто запитувані поля — це прискорює запити в 5 разів.

Чому PlanetScale — найкращий вибір для serverless MySQL?

PlanetScale вирішує головні болі: відставання реплікації, блокування при ALTER TABLE, необхідність DBA. Serverless MySQL підхід виключає простої: навіть при пікових навантаженнях у 100 тис. операцій на секунду база не йде в офлайн. Економія на адмініструванні БД досягає 40% — сервером керуєте не ви, а PlanetScale.

Як ми налаштовуємо PlanetScale під ваш проєкт

Наша команда має 5+ років досвіду роботи з PlanetScale і впровадила її на 50+ проєктах. Ось приклад із практики: для великого інтернет-магазину з 200 ГБ даних ми мігрували базу на PlanetScale. Час виконання складних запитів скоротився на 60%, а витрати на адміністрування зменшилися на 40%. Процес налаштування включає:

1. Аудит поточної схеми та навантаження: аналізуємо розмір даних, запити, піки. Виявляємо неоптимальні індекси. Оцінка — відповідь протягом дня.
2. Налаштування branching workflow: визначаємо стратегію відгалуження (feature-гілки, hotfix-гілки).
3. Інтеграція з CI/CD: автоматичні deploy requests з гілок при пул-реквестах.
4. Міграція даних: імпорт дампу, перевірка консистентності, перемикання трафіку.
5. Документація та навчання: передаємо схему відгалуження, навчаємо команду роботі з deploy requests.

Замовте аудит поточної схеми — це безкоштовно.

Що входить у налаштування та які терміни?

• Повне налаштування PlanetScale: проєкт, регіон, користувачі.
• Інтеграція з ORM (Prisma, TypeORM, Drizzle) або кастомним підключенням.
• Налаштування CI/CD для автоматичних deploy requests.
• Документація з архітектури відгалуження.
• Навчання команди (2–4 години).
• Підтримка протягом місяця після впровадження.

Терміни: типовий проєкт — 1–2 дні, з перенесенням даних — до 3 днів. Вартість розраховується індивідуально. Отримайте консультацію: зв'яжіться з нами для оцінки вашої бази даних.

Які помилки допускають при переході на PlanetScale?

Які обмеження у PlanetScale?

• Відсутні збережені процедури та тригери.
• Відсутні обмеження зовнішніх ключів на рівні БД.
• Відсутній SELECT ... FOR UPDATE у деяких конфігураціях.
• Максимальний розмір рядка — 65535 байт.
• Безкоштовний план: 5 ГБ сховища, 1 млрд row reads/місяць.

Економія на адмініструванні БД досягає 40% — сервером керуєте не ви, а PlanetScale. Оцінимо проєкт безкоштовно: напишіть, відповімо протягом дня.