Почему я снова и снова тянусь к скучным технологиям

Сразу оговорюсь о том, чего я не говорю

Я не говорю, что новые технологии плохие или что никогда не стоит ничего пробовать. Я использовал новые базы данных, играл с edge-рантаймами, экспериментировал с ORM, которые обещают упростить всё. Часть из этого реально интересна.

Но после нескольких лет поставки реальных продуктов — BookUp, ERP InterRail, проекты для клиентов — я снова и снова прихожу в одно место: Postgres, NestJS, TypeScript, Redis для кэширования и очередей. Примерно один и тот же стек.

Вот почему я с этим в мире.

Postgres делает всё

Я имею в виду буквально. Postgres обрабатывает:

• Реляционные данные с внешними ключами и джойнами (очевидно)
• JSON и JSONB столбцы когда нужна гибкая схема
• Полнотекстовый поиск, достаточно хороший для большинства приложений
• Геопространственные запросы через PostGIS
• Row-level security для мультитенантности

Каждый раз, когда я думал "может, нужна отдельная база для X", честный ответ был "нет, Postgres может X." Стоимость управления одной базой данных намного ниже, чем тремя.

-- Postgres: мультитенантность, метаданные JSONB и фильтрация в одном запросе
SELECT b.id, b.starts_at, b.metadata->>'notes' AS notes
FROM bookings b
WHERE b.tenant_id = $1
  AND b.starts_at > now()
ORDER BY b.starts_at;

NestJS упрямый в правильных местах

Я строил API на Express, Fastify, Hono и NestJS. Express и Fastify отлично подходят для небольшого. По мере роста проектов приходится строить свои конвенции — dependency injection, структуру модулей, паттерны guard/middleware.

В NestJS всё это встроено. Тяжелее, но когда присоединяешься к проекту или вводишь кого-то, конвенции уже есть. DI-система позволяет тестировать логику сервиса без запуска базы данных.

Аргумент надёжности

Вот в чём дело со скучными технологиями: они ломаются скучными способами. Когда у Postgres проблема, есть ответ на StackOverflow. Когда у новой базы данных проблема, вы читаете GitHub issues трёхнедельной давности.

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

Когда я всё же тянусь к чему-то другому

Очереди: использую BullMQ на Redis. Реальное время: WebSocket когда нужно. Поиск: если основной сценарий приложения — поиск, Elasticsearch имеет смысл.

Паттерн: добавляю что-то новое, когда есть конкретная потребность, которую скучный стек реально не может хорошо закрыть. Не потому что интересно, не потому что это в тренде.

Скучное — не то же самое, что простое. Postgres сложен. NestJS сложен. Но они проверены боем, и их сложность задокументирована. Это важнее новизны, когда поставляешь реальные вещи.