Безпечне підключення PostgreSQL, MySQL та MongoDB у Retool

Під час налаштування Retool для внутрішніх інструментів часто виникають проблеми: неправильні права доступу, небезпечні підключення, N+1 запити, які вбивають продуктивність. Типовий кейс — розробник дає базі суперкористувача, а потім дивується, чому дані витекли. Або підключає MongoDB без SSL, і трафік іде відкрито. Нещодавно клієнт втратив 2 дні на розгортання адмінки через некоректні права — ми вирішили проблему за 3 години. Ми налаштовуємо підключення до баз даних (PostgreSQL, MySQL, MongoDB) з нуля: від створення окремого користувача до налаштування SSH-тунелю. Нижче — типові конфіги, best practices та реальні граблі, яких ми уникаємо.

Проблеми, які вирішуємо

N+1 запити — одна з головних причин гальмування. Retool без кешування може виконувати десятки запитів на відмальовування віджета. Наприклад, список клієнтів із їхніми замовленнями: без джойнів отримуємо 1 запит на клієнта + N на замовлення. Це збільшує час завантаження на 500%. Рішення — використовувати параметризовані запити з LEFT JOIN всередині одного виклику.

Небезпечні підключення — база з публічним IP, пароль суперкористувача в плейнтексті, відсутність SSL. В одному проєкті ми виявили, що до MongoDB можна було підключитися без пароля з будь-якої точки світу. Довелося терміново змінювати налаштування.

Права доступу — часто дають надто широкі ролі. Через це випадкове видалення даних або SQL-ін'єкції. Ми завжди створюємо користувача з мінімальними привілеями.

Що таке N+1 запити і як їх уникнути?

N+1 виникає, коли для кожного батьківського об'єкта виконується окремий дочірній запит. У Retool це особливо помітно на таблицях із лукапом. Оптимальний підхід — один SQL-запит з JOIN, агрегацією або з використанням виразів IN (). Наприклад, замість:

SELECT * FROM customers; -- 1 запит
-- для кожного customer виконується:
SELECT * FROM orders WHERE customer_id = $1;

Використовуйте:

SELECT c.*, o.order_count
FROM customers c
LEFT JOIN (
  SELECT customer_id, COUNT(*) as order_count
  FROM orders
  GROUP BY customer_id
) o ON c.id = o.customer_id;

Типова затримка через N+1 — 2-3 секунди на сторінку. Після оптимізації запит виконується за 50 мс.

Підключення PostgreSQL, MySQL та MongoDB

Retool підтримує популярні БД. Розглянемо підключення кожної. Важливо: всі з'єднання мають бути зашифровані, а користувачі — з обмеженими правами.

PostgreSQL

Створіть ресурс у Retool: Resources → Create New → PostgreSQL. Вкажіть:

Host: db.production.example.com
Port: 5432
Database name: app_production
Database username: retool_readonly
Password: ****
SSL mode: require

Приклад SQL для створення користувача з правами лише на читання:

CREATE USER retool_readonly WITH PASSWORD 'secure_password';
GRANT CONNECT ON DATABASE app_production TO retool_readonly;
GRANT USAGE ON SCHEMA public TO retool_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO retool_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO retool_readonly;

MySQL

Для MySQL також використовуйте окремого readonly-користувача. Обов'язково увімкніть SSL: Required та вкажіть charset utf8mb4. Порт за замовчуванням 3306.

MongoDB

Рядок підключення: mongodb://user:pass@host:27017/db?ssl=true. У production використовуйте replica set з retryWrites=true. Порт за замовчуванням 27017.

Як налаштувати SSH-тунель?

Якщо база даних не має публічного IP, використовуйте SSH-тунель. Retool підтримує його налаштування за пару хвилин.

1. На bastion-сервері створіть користувача retool-tunnel з обмеженими командами.
2. У Retool при створенні ресурсу увімкніть SSH tunnel та вкажіть:
   • SSH host: bastion.example.com
   • SSH port: 22
   • SSH username: retool-tunnel
   • SSH private key: [вставити ключ]
3. На bastion-сервері обмежте команди:

Match User retool-tunnel
  ForceCommand /bin/false
  PermitTunnel yes
  AllowTcpForwarding yes

Параметризовані запити проти SQL-ін'єкцій

Retool автоматично екранує змінні в {{ }}. Використовуйте їх завжди. Приклад безпечного оновлення:

UPDATE users
SET status = {{ statusSelect.value }},
    updated_at = NOW(),
    updated_by = {{ current_user.email }}
WHERE id = {{ usersTable.selectedRow.data.id }}
  AND status != {{ statusSelect.value }}

Ніколи не конкатенуйте рядки вручну — це прямий шлях до ін'єкцій. Згідно з Retool Documentation, параметризовані запити — єдиний безпечний спосіб.

Права доступу для Retool

Краще створити окремого користувача лише для читання. Якщо потрібен запис — дайте права тільки на конкретні таблиці. Приклад для PostgreSQL:

GRANT SELECT, UPDATE ON users TO retool_ops;
GRANT SELECT, INSERT, UPDATE ON orders TO retool_ops;

Налаштування під ключ: що входить

Ми надаємо повний цикл робіт:

• Аналіз архітектури та вибір оптимального стеку
• Створення користувачів БД з мінімальними правами
• Налаштування SSH-тунелю та SSL
• Конфігурація ресурсів у Retool
• Написання перших 5–10 запитів та віджетів
• Документація щодо підключення та безпеки
• Навчання команди (1 година)

Термін — від 1 дня. Вартість розраховується індивідуально залежно від складності.

Типові помилки при налаштуванні

• Неправильний хост: використовуйте приватний IP, якщо Retool і база в одній мережі.
• Пропущений firewall: перевірте, що IP Retool дозволений у security group.
• Невірний порт: уточніть порт у адміністратора БД.
• Відсутність SSL: завжди вмикайте SSL mode require або ssl=true.

Чому варто довірити налаштування нам?

У нас 5+ років досвіду роботи з Retool та базами даних. Ми гарантуємо безпеку та продуктивність. Налаштували понад 50 проєктів. Retool у 5 разів швидший за самописні адмінки — ви економите до 40% часу на розробку. Замовте налаштування Retool під ключ та зекономте час своєї команди. Отримайте консультацію — ми оцінимо ваш проєкт.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

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

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.