Запускал небольшой AI-сервис — нужно было хранить историю чатов, профили пользователей и embeddings для RAG-пайплайна. Казалось бы, простая задача. Но когда сел выбирать базу данных, у каждого варианта нашлась какая-то неочевидная засада, которую в туториалах не упоминают.
Попробовал все три — Supabase, PlanetScale и Neon. Расскажу что получил на практике, а не то что написано в маркетинговых лендингах.
Supabase: когда хочется всего сразу
Начал с Supabase, потому что все вокруг его советовали. Первые пару дней я понимал почему: разворачиваешь Postgres, получаешь автоматически сгенерированный REST API, аутентификацию, хранилище файлов и edge-функции — всё в одном дашборде. Для прототипа почти идеально.
Конкретный пример: мне нужно было хранить векторные embeddings и делать similarity search. Supabase поддерживает pgvector из коробки — одна строчка в SQL-редакторе и расширение включено. Это сэкономило полдня возни с настройкой отдельного векторного хранилища.
Дальше началось интересное. На бесплатном тарифе проект "засыпает" после нескольких дней неактивности, и первый запрос после пробуждения может ждать 20-30 секунд. Для AI-приложения, где пользователь ожидает быстрого ответа, это катастрофа. Отключить режим сна стоит $25 в месяц — для раннего прототипа сумма спорная.
Ещё один момент — row-level security. В теории мощная штука: описываешь прямо в базе кто что может читать, и фронтенд обращается к Supabase напрямую без промежуточного сервера. На практике я потратил несколько часов на отладку политик, которые вели себя не так как ожидалось. Документация есть, но разрыв между "понял концепцию" и "оно работает правильно" оказался шире чем хотелось бы.
PlanetScale: MySQL с амбициями
PlanetScale попробовал из любопытства — это MySQL с архитектурой, вдохновлённой Vitess, той самой что используют в YouTube. Главная фишка — branching: создаёшь отдельную ветку схемы, вносишь изменения, потом мёрджишь в продакшн без даунтайма. Звучит круто, особенно если уже работаешь в git-парадигме.
Branching действительно работает хорошо. Тестировал изменение схемы для новой фичи в отдельной ветке и деплоил без страха что что-то сломается в основной базе. Реально снижает тревогу при изменениях схемы.
Но для AI-проектов у PlanetScale есть фундаментальное ограничение: никаких foreign keys. Это не баг — ограничения внешних ключей несовместимы с горизонтальным шардингом, это архитектурное решение. Эмулировать их на уровне приложения можно, но это другая история. Если у тебя сложные связи между сущностями — embeddings, документы, пользователи, разговоры — отсутствие FK-ограничений на уровне базы начинает раздражать довольно быстро.
Дальше — деньги. В начале 2024 года PlanetScale убрал бесплатный тариф. Минимум теперь $39 в месяц, а для проверки идеи это многовато, когда конкуренты предлагают бесплатные тиры.
Плюс pgvector тут нет — это MySQL. Для векторного поиска нужно подключать что-то отдельное: Pinecone, Weaviate, на выбор. Дополнительный сервис, дополнительные деньги, дополнительная сложность.
Neon: Postgres с холодным стартом
Neon я оставил на третий заход, и в итоге он оказался наиболее интересным для моего сценария. Serverless Postgres с ветвлением как у PlanetScale — но без ограничений MySQL и с поддержкой pgvector.
Главное что понравилось — архитектура разделяет compute и storage. Можно поднять несколько веток базы для разработки, стейджинга и тестов, и все они будут шарить одно хранилище. Ветка для тестов не копирует гигабайты — просто указывает на тот же storage с точкой ветвления. Удобно и экономит место.
Бесплатный тир в Neon щедрее чем у Supabase, и "засыпания" такого агрессивного нет. Холодный старт есть, но занимает 1-3 секунды, а не полминуты. Для AI-сервиса с неравномерной нагрузкой — утром много запросов, ночью тишина — это важно.
Споткнулся на connection pooling. Serverless-функции любят открывать по новому соединению на каждый запрос, и Postgres это плохо переносит. В Neon есть встроенный пулер через параметр pgbouncer=true в строке подключения, но я не сразу об этом узнал. Первые дни видел ошибки "too many connections". Полчаса отладки, правильная строка подключения — проблема ушла. Лучше знать об этом заранее, чем разбираться на ходу.
Embeddings и векторный поиск: у кого лучше
Для AI-приложений это часто ключевой вопрос, поэтому остановлюсь отдельно.
Supabase и Neon — оба Postgres, оба поддерживают pgvector. Разница в удобстве: у Supabase расширение включается одной командой через UI, у Neon — через CREATE EXTENSION vector в SQL, тоже просто. Производительность при небольших объёмах, до нескольких сотен тысяч векторов, у обоих приемлемая.
PlanetScale здесь проигрывает по определению. Нет pgvector, нет нативного векторного поиска. Либо храни embeddings как JSON и делай поиск на стороне приложения — медленно и больно при любом объёме — либо добавляй отдельную векторную базу.
Вывод, который я сделал для себя: если проект хоть как-то завязан на embeddings или semantic search, Postgres-based решения выигрывают уже только за это.
Чем я в итоге пользуюсь и почему
На продакшн выбрал Neon. Не потому что он идеален, а потому что для моего сценария совпало несколько факторов: Postgres с pgvector, адекватный бесплатный тир на старте, branching для безболезненных изменений схемы и более предсказуемое поведение при переменной нагрузке.
Supabase держу как вариант на будущее — если проект дорастёт до момента где нужна встроенная аутентификация и storage, его экосистема сэкономит время. К PlanetScale в AI-контексте пока не вижу смысла возвращаться. Может, в другом проекте, где MySQL-специфика и горизонтальный шардинг будут важнее.
Выбор базы данных выглядит как скучная инфраструктурная задача. До тех пор пока не теряешь полчаса на отладку connection pool или не обнаруживаешь что прототип не поднимается 30 секунд. После этого начинаешь относиться к этому выбору серьёзнее.
