Alex.Miller
New member
Каждый раз, когда мы собираемся командой и обсуждаем стек для нового продукта, разговор заканчивается одинаково: берём PostgreSQL и не выдумываем. Я сам так делал лет пять и считал это признаком зрелости. Но за последние два года я трижды осознанно от него отказывался — и ни разу не пожалел. Хочу разложить по полочкам, потому что в комментариях к прошлым постам эта тема всплывает с завидной регулярностью.
Первый стартап был B2B-сервисом для логистики. Мы взяли Postgres под всё сразу: транзакции, аналитику, очереди задач и поиск по документам. Первые месяцы — сплошное удовольствие. Потом добавили JSONB для гибких полей заказов, навесили индексы, и на двадцати миллионах строк дежурный начал просыпаться по ночам. Автовакуум не успевал за нашим темпом записи, таблицы раздувались, а дашборд для инвесторов собирал метрики прямыми запросами по продакшену. Классическая ловушка: одна база героически тянет работу четырёх разных систем.
Что мы сделали: вынесли аналитику в отдельное колоночное хранилище, в Postgres оставили только честный транзакционный контур, а тяжёлые фоновые отчёты увели на реплику. Время построения отчёта упало с сорока секунд до двух, и жизнь наладилась. Я не против Postgres — я против того, чтобы складывать в него всё, что попадётся под руку, только потому что он уже установлен.
Второй случай — маркетплейс с подписками и биллингом. Проблема была не в нагрузке, а в модели данных: цены, скидки и тарифные планы менялись едва ли не каждую неделю, а реляционная схема требовала миграций по три раза в день. Мы переехали на документную базу, взяли MongoDB, и выпустили нужную фичу буквально за вечер. Да, пришлось отказаться от части гарантий целостности, зато команда наконец начала двигаться, а не спорить о нормальных формах до пенсии.
Третий случай оказался совсем неожиданным. Мы делали простой MVP для внутреннего инструмента: десять пользователей, пять тысяч записей, никакой сложной аналитики. Я честно собирался поднять Postgres в контейнере, а в итоге залил всё в локальный файл SQLite. И знаете, работает прекрасно. Бэкап — это копирование одного файла, деплой — это тоже копирование одного файла. На вопрос из зала про масштабирование у меня один ответ: будем масштабироваться, когда появится пользователь номер одиннадцать, а не раньше.
Теперь мой рабочий чек-лист перед выбором хранилища. Первое: какие у нас запросы — точечные по ключу или тяжёлые сканы по миллиардам строк? Второе: нужны ли строгие транзакции и внешние ключи или хватит приблизительной согласованности? Третье: меняется ли схема быстрее, чем мы успеваем её версионировать? Четвёртое: кто будет дежурить и умеет ли этот человек читать планы запросов? И пятое, самое важное: есть ли у нас время собирать из трёх систем одну? Если на первые два вопроса ответы звучат как «точечные» и «да, нужны» — берите Postgres и не мучайте себя. Если на третий — «каждую неделю» — присмотритесь к документной модели. Если данных мало, а время дороже архитектуры — не бойтесь самого простого решения.
И главное, про людей. База — это не только движок, это ещё и команда, которая умеет её эксплуатировать. Гениально подобранное хранилище, которое никто не умеет мониторить и бэкапить, приносит куда больше вреда, чем скучный Postgres в руках опытного инженера. Я проходил оба сценария и во втором плакал заметно меньше.
Поэтому фразу про то, что PostgreSQL не лучший выбор, я сегодня читаю как «PostgreSQL — не единственный выбор». Он остаётся моим дефолтом, но дефолт — это стартовая точка, а не религия. Кстати, в последнем проекте мы спокойно держим сразу две базы и живём прекрасно. А у вас был момент, когда вы отказались от привычной базы в пользу чего-то неожиданного и от этого только выиграли? Расскажите, что взяли и почему — обожаю такие истории, они учат лучше любой документации.
Первый стартап был B2B-сервисом для логистики. Мы взяли Postgres под всё сразу: транзакции, аналитику, очереди задач и поиск по документам. Первые месяцы — сплошное удовольствие. Потом добавили JSONB для гибких полей заказов, навесили индексы, и на двадцати миллионах строк дежурный начал просыпаться по ночам. Автовакуум не успевал за нашим темпом записи, таблицы раздувались, а дашборд для инвесторов собирал метрики прямыми запросами по продакшену. Классическая ловушка: одна база героически тянет работу четырёх разных систем.
Что мы сделали: вынесли аналитику в отдельное колоночное хранилище, в Postgres оставили только честный транзакционный контур, а тяжёлые фоновые отчёты увели на реплику. Время построения отчёта упало с сорока секунд до двух, и жизнь наладилась. Я не против Postgres — я против того, чтобы складывать в него всё, что попадётся под руку, только потому что он уже установлен.
Второй случай — маркетплейс с подписками и биллингом. Проблема была не в нагрузке, а в модели данных: цены, скидки и тарифные планы менялись едва ли не каждую неделю, а реляционная схема требовала миграций по три раза в день. Мы переехали на документную базу, взяли MongoDB, и выпустили нужную фичу буквально за вечер. Да, пришлось отказаться от части гарантий целостности, зато команда наконец начала двигаться, а не спорить о нормальных формах до пенсии.
Третий случай оказался совсем неожиданным. Мы делали простой MVP для внутреннего инструмента: десять пользователей, пять тысяч записей, никакой сложной аналитики. Я честно собирался поднять Postgres в контейнере, а в итоге залил всё в локальный файл SQLite. И знаете, работает прекрасно. Бэкап — это копирование одного файла, деплой — это тоже копирование одного файла. На вопрос из зала про масштабирование у меня один ответ: будем масштабироваться, когда появится пользователь номер одиннадцать, а не раньше.
Теперь мой рабочий чек-лист перед выбором хранилища. Первое: какие у нас запросы — точечные по ключу или тяжёлые сканы по миллиардам строк? Второе: нужны ли строгие транзакции и внешние ключи или хватит приблизительной согласованности? Третье: меняется ли схема быстрее, чем мы успеваем её версионировать? Четвёртое: кто будет дежурить и умеет ли этот человек читать планы запросов? И пятое, самое важное: есть ли у нас время собирать из трёх систем одну? Если на первые два вопроса ответы звучат как «точечные» и «да, нужны» — берите Postgres и не мучайте себя. Если на третий — «каждую неделю» — присмотритесь к документной модели. Если данных мало, а время дороже архитектуры — не бойтесь самого простого решения.
И главное, про людей. База — это не только движок, это ещё и команда, которая умеет её эксплуатировать. Гениально подобранное хранилище, которое никто не умеет мониторить и бэкапить, приносит куда больше вреда, чем скучный Postgres в руках опытного инженера. Я проходил оба сценария и во втором плакал заметно меньше.
Поэтому фразу про то, что PostgreSQL не лучший выбор, я сегодня читаю как «PostgreSQL — не единственный выбор». Он остаётся моим дефолтом, но дефолт — это стартовая точка, а не религия. Кстати, в последнем проекте мы спокойно держим сразу две базы и живём прекрасно. А у вас был момент, когда вы отказались от привычной базы в пользу чего-то неожиданного и от этого только выиграли? Расскажите, что взяли и почему — обожаю такие истории, они учат лучше любой документации.