Уявіть: ваш проєкт на Payload CMS з MongoDB, але через місяць LCP перевищує 4 секунди. Причина — відсутність індексів на дату створення. Типова ситуація: розробник не налаштував складові індекси, і кожен запит списку постів сканує всю колекцію. Або навпаки — PostgreSQL без індексів на datetime перетворює пагінацію на гальма. На одному проєкті відсутність індексів на createdAt призвела до зростання LCP з 1.2 до 4.1 секунди — падіння продуктивності на 240%. Після налаштування складових індексів TTFB знизився до 200 мс. Наш досвід — 5+ років роботи з Payload CMS, десятки проєктів від блогів до enterprise-порталів. Ми налаштовуємо базу так, щоб вона не вимагала доопрацювань півроку, а навантаження до 10 000 RPM не викликало паніки.
Чому вибір адаптера БД критичний для Payload CMS?
Payload CMS підтримує два адаптери: PostgreSQL через Drizzle ORM та MongoDB через Mongoose. Кожен має свої сильні сторони, але неправильний вибір призводить до проблем: N+1 запити, повільні міграції, падіння TTFB.
Помилки типізації та N+1 запити — інтеграція payload cms
Payload часто генерує багато запитів при вкладених зв'язках. Наприклад, список постів з авторами та тегами: без eager-loading кожен пост викликає окремий select. У PostgreSQL ми вирішуємо це через Drizzle findMany з deep відношенням та select — один запит замість N+1. У MongoDB — агрегація $lookup з індексами.
Провал міграції на production
Пуш схеми через Drizzle в production може скинути дані або видалити колонки. Ми завжди вимикаємо push: false і створюємо міграції з рев'ю. В одному проєкті клієнт вніс поле без чек-листа — міграція видалила таблицю версій (_posts_v). Відновили з бекапу за 1 годину. Навантажувальне тестування виявило, що 60% проблем з TTFB пов'язані з відсутністю індексів.
Відсутність індексів — повільний пошук
За замовчуванням Payload не створює індекси на всі поля. Результат: TTFB часто 2-3 секунди при фільтрації за статусом та категорією. Ми додаємо складові індекси на часто запитувані комбінації — це знижує час запиту на 80%.
Як налаштувати міграції для PostgreSQL та MongoDB в Payload?
Міграції — ключовий елемент production-налаштування. Для PostgreSQL використовуємо Drizzle ORM з вимкненим push. Команди:
npx payload migrate:create # Згенерувати npx payload migrate # Застосувати npx payload migrate:down # Відкотити npx payload migrate:status # Перевірити статус Для MongoDB міграції не потрібні — Mongoose синхронізує схему на льоту. Але в production рекомендується контроль змін через скрипти. У 80% випадків проблема вирішується доопрацюванням індексів. Економія часу розробки — до 40%.
Як оптимізувати запити в Payload CMS?
Ми використовуємо три методи. По-перше, додаємо індекси на всі поля фільтрації та сортування. Для PostgreSQL — складові індекси (наприклад, на status + createdAt), для MongoDB — db.collection.createIndex(). По-друге, налаштовуємо пул з'єднань: max: 10 для більшості проєктів, з PgBouncer для високих навантажень. По-третє, для складних звітів робимо прямі запити через Drizzle ORM — це швидше, ніж REST API.
Результати оптимізації на прикладі:
| Тип запиту | До оптимізації | Після оптимізації |
|---|---|---|
| Список постів з авторами | 450 ms | 45 ms |
| Пошук за категоріями | 300 ms | 60 ms |
Приклад прямого запиту через Drizzle
const db = payload.db.drizzle const result = await db .select({ id: posts.id, title: posts.title }) .from(posts) .where(eq(posts.status, 'published')) .orderBy(sql`created_at DESC`) .limit(10) Які переваги дає правильне налаштування індексів?
Правильні індекси — основа продуктивності. TTFB знижується до 200 мс, LCP — до 1.5 секунд. На одному проєкті після додавання складових індексів на status та category кількість запитів до бази скоротилася в 10 разів. Це особливо важливо для сайтів з високою відвідуваністю.
Порівняння адаптерів: PostgreSQL vs MongoDB
| Критерій | PostgreSQL | MongoDB |
|---|---|---|
| Строгість схеми | Висока (міграції обов'язкові) | Гнучка (схема створюється на льоту) |
| Складні зв'язки | JOIN — ефективно до 5 таблиць | $lookup — повільно без індексів |
| Версіонування | Окремі таблиці _v (великий об'єм) |
Вкладені версії (компактно) |
| Production-рекомендація | Структуровані дані з чіткими зв'язками | Прототипи, контент з частими змінами |
PostgreSQL краще MongoDB для строгих схем у 2-3 рази за швидкістю зв'язних запитів (наш тест: 10 таблиць, 100k записів, JOIN vs $lookup). Але якщо вам потрібна гнучкість полів — MongoDB виграє в простоті.
Що ви отримуєте в результаті налаштування
| Етап | Результат |
|---|---|
| Аудит поточної схеми | Звіт про індекси, N+1 запити та конфігурацію пулу |
| Налаштування адаптера | Конфіг payload.config.ts з оптимізаціями |
| Створення міграцій | Скрипти міграцій з рев'ю |
| Навантажувальне тестування | Протокол тестів Artillery |
| Документація | README та інструкція з експлуатації |
| Гарантія | 30 днів підтримки після запуску |
Процес роботи
- Аналітика: вивчаємо структуру даних, навантаження, вимоги до локалізації та версій.
- Проєктування: обираємо адаптер, проєктуємо індекси, налаштовуємо пул з'єднань.
- Реалізація: конфігурація Payload, створення міграцій, інтеграція з зовнішніми БД (якщо потрібно).
- Тестування: навантажувальне тестування (Artillery), перевірка LCP/INP, налагодження повільних запитів.
- Деплой: налаштування SSL, PgBouncer для PostgreSQL, Atlas для MongoDB, моніторинг через Grafana.
Ми гарантуємо стабільність роботи бази даних і надаємо підтримку протягом 30 днів після запуску. Зв'яжіться з нами для консультації щодо вашого проєкту. Ми оцінимо поточну архітектуру та запропонуємо оптимальні рішення. Замовте налаштування Payload CMS під ключ — і забудьте про проблеми з базами даних.
Для глибокого розуміння адаптерів вивчіть офіційну документацію: PostgreSQL та MongoDB.
Згідно з документацією Payload CMS, для production рекомендується використовувати PostgreSQL з Drizzle ORM.