Шаблоны Postgres, которые мы используем в проектах клиентов

Postgres остаётся нашим стандартом для транзакционных продуктов, потому что он предсказуем, наблюдаемый и хорошо понятен. Мы стандартизируем инструменты миграции и наименования, чтобы любой инженер мог войти в проект за один день.

Мы избегаем экзотических хранилищ данных, если конкретный случай использования не требует этого. Для 95 % приложений достаточно правильно настроенного экземпляра Postgres.

Индексы не просто создаются и забываются. Мы фиксируем медленные запросы в промежуточной среде, анализируем планы до развертывания и избегаем преждевременного использования JSONB, если схемы доступа к нему действительно не требуют.

• Композиционные индексы для паттернов фильтрации + сортировки, которые встречаются вместе
• Частичные индексы для редких булевых значений, например is_archived = false
• Избегайте индексации колонок с низкой кардинальностью в изоляции
• Пересматривайте индексы после каждого десятикратного скачка трафика

Безопасность на уровне строк и границы аренды проектируются заранее для мульти-арендного SaaS. Внедрение изоляции после запуска болезненно и рискованно.

1. 01tenant_id во всех таблицах, привязанных к аренде — без исключений
2. 02Политики RLS тестируются интеграционными тестами, а не надеждой
3. 03Фоновые задания всегда устанавливают контекст сессии перед запросами

Слои API никогда не раскрывают сырые SQL-формы клиентам. DTO и валидация на границе сохраняют стабильность контрактов, пока схемы меняются под капотом.

Отделив схему базы данных от ответа API, мы можем оптимизировать запросы, не ломая мобильные приложения и потребителей публичного API.