ИИ для баз данных — это генерация SQL по описанию задачи, объяснение и отладка запросов, проектирование схем и агенты, которые сами подключаются к базе через MCP-серверы и выполняют запросы. Разбираем промпты, безопасность (read-only режим, никаких прав на прод) и типовые ошибки — например, галлюцинации имён колонок.
Запрос к базе — самая частая рутина разработчика, аналитика и тестировщика. Написать SQL по описанию задачи, объяснить, почему запрос медленный, спроектировать схему под новую фичу. В 2026 году эти задачи берут на себя агенты, которые сами подключаются к базе данных, читают схему и выполняют запросы, — а обычные чат-боты, выдающие код для копирования, уходят на второй план. Разберём, как это работает, где границы и как не дать агенту натворить дел.
Что умеет ИИ в базах данных
Четыре типовые задачи, которые закрывает современная языковая модель.
1. Генерация SQL по описанию. Вы описываете задачу словами, модель возвращает запрос. Чем точнее схема таблиц в промпте, тем надёжнее результат — об этом ниже в разделе про типовые ошибки.
2. Объяснение и отладка запросов. Модель объясняет, что делает чужой SQL, находит ошибки, упрощает вложенные подзапросы, подсказывает, где не хватает индекса.
3. Проектирование схем. Сгенерировать таблицы под описание, спроектировать миграцию, добавить ограничения и внешние ключи. Агент с доступом к существующей базе сперва изучит текущую схему и предложит миграцию с учётом реальных таблиц.
4. Агент, который сам ходит в базу. Через MCP агент получает инструменты: выполнить запрос, посмотреть схему, посчитать план выполнения. Тогда диалог выглядит так: «сколько заказов за месяц?» — агент сам пишет SQL, выполняет его и возвращает цифру.
Разница между чат-ботом и агентом — в доступе:
| Чат-бот (ChatGPT, Gemini) | Агент с MCP-сервером БД | |
|---|---|---|
| Видит схему базы | Нет, только то, что вы вставили в промпт | Да, через инструменты и ресурсы сервера |
| Выполняет SQL | Нет, код нужно копировать в клиент | Да, сам запускает запрос и возвращает результат |
| Проверяет результат | Нет | Да: ошибка запроса попадает обратно, агент её чинит |
| Главный риск | Угадывает имена колонок | Те же галлюцинации плюс право выполнить запрос |
Как агент подключается к базе данных
Соединение идёт через MCP-сервер: отдельный процесс, который знает протокол, держит подключение к базе и отдаёт агенту набор инструментов. Агент — Claude Code, OpenCode, Cursor — говорит с сервером по stdio или HTTP, а сервер — с базой по SQL.
Какие бывают MCP-серверы для баз данных
DBHub (github.com/bytebase/dbhub, ~3,3 тыс. звёзд, MIT) — минимальный MCP-сервер для PostgreSQL, MySQL, MariaDB, SQL Server и SQLite. По умолчанию у него два инструмента — execute_sql и search_objects (поиск по схемам, таблицам и колонкам) — и это около 1,4 тыс. токенов на инициализацию, то есть в 13–14 раз меньше, чем у громоздких конкурентов (сравнение с ними есть прямо в README). У сервера есть read-only режим, лимит строк и таймаут запроса. Это официальный пример подключения к PostgreSQL в доках Claude Code.
PostgreSQL reference server (@modelcontextprotocol/server-postgres) — эталонный сервер из репозитория MCP, выполняет только read-only запросы внутри транзакции READ ONLY и отдаёт схему таблиц как ресурсы. Репозиторий reference-серверов переехал в архив (servers-archived), а за актуальными серверами теперь ходят в официальный реестр.
Postgres MCP Pro (github.com/crystaldba/postgres-mcp, ~3,2 тыс. звёзд) — сервер «потяжелее»: кроме запросов умеет строить EXPLAIN-планы, подбирать индексы и проверять здоровье базы. Ключевое — режимы доступа: unrestricted (полный доступ, для разработки) и restricted (только чтение + ограничение времени запроса). В restricted-режиме сервер дополнительно парсит SQL библиотекой pglast и отклоняет COMMIT и ROLLBACK — так агент не может обойти read-only транзакцию командой ROLLBACK; DROP TABLE users;.
Где искать остальные серверы — официальный реестр registry.modelcontextprotocol.io, по запросу вроде «postgres» или «database».
Подключение к агенту: два примера
Claude Code — добавить сервер одной командой (пример прямо из документации):
claude mcp add --transport stdio db -- npx -y @bytebase/dbhub \
--dsn "postgresql://readonly:pass@prod.db.com:5432/analytics"
Обратите внимание на строку подключения: readonly — отдельный пользователь базы без прав на запись. Документация Claude Code прямо требует этого: «Use a read-only database user in the connection string so the queries Claude runs can’t modify data». После подключения проверяется статус командой /mcp, и можно задавать вопросы обычным языком.
OpenCode — серверы описываются в opencode.json (документация opencode.ai/docs/mcp-servers):
{
"mcp": {
"db": {
"type": "local",
"command": ["npx", "-y", "@bytebase/dbhub", "--dsn", "postgres://user:pass@localhost:5432/mydb"],
"enabled": true
}
}
}
Для удалённых серверов есть "type": "remote" с URL и авторизацией через opencode mcp auth. Учтите: каждый подключённый MCP-сервер добавляет токены в контекст, поэтому держите включёнными только те, что нужны сейчас.
Примеры промптов: схема таблиц + задача
Правило, которое убирает большинство ошибок: дайте агенту схему в том же промпте. Тогда модель не угадывает имена таблиц и колонок, а опирается на факты.
Пример промпта для генерации SQL:
Схема таблицы orders:
- id BIGINT PRIMARY KEY
- user_id BIGINT NOT NULL
- amount NUMERIC(10,2) NOT NULL
- status TEXT ('paid', 'pending', 'cancelled')
- created_at TIMESTAMPTZ NOT NULL
Задача: посчитай средний чек за последние 30 дней
только по оплаченным заказам. Верни только SQL.
Модель вернёт:
SELECT AVG(amount)
FROM orders
WHERE status = 'paid'
AND created_at >= now() - interval '30 days';
Когда агент подключён к базе через MCP, промпт ещё короче — схему он возьмёт сам. Примеры запросов из документации Claude Code: «What’s our total revenue this month?», «Show me the schema for the orders table», «Find customers who haven’t made a purchase in 90 days».
Для генерации SQL хорошие модели на момент публикации — Claude (Sonnet/Opus), Gemini, а среди локальных — Qwen3-Coder и семейство Mistral для text2SQL. Про запуск локальных моделей для кодинга — в нашей статье про Qwen3-Coder через Ollama.
Кейс 1: бот-аналитик в российской компании на локальных моделях
Команда ecom.tech (российская компания, 1–5 тыс. сотрудников) описала на Хабре свой продукт «бот-аналитик»: сотрудник задаёт вопрос на естественном языке — «Сколько сырков заказали в Питере?» — нейросеть превращает его в SQL, выполняет в изолированной базе с синтетическими данными и возвращает понятный ответ.
Главное ограничение — данные компании не должны уходить наружу, поэтому большая внешняя модель отпала: «Ни одна служба безопасности не пропустит подобное решение для работы на настоящих данных». Решение — open-weight модели во внутреннем контуре: одна для понимания текста и ответа (семейство Gemma), вторая для text2SQL (семейство Mistral). Кандидатов проверяли на бенчмарках SPIDER, BIRD и PAUQ, а затем на собственной выборке из ~50 реальных вопросов. Тюнинг промптов (перевод системного промпта на английский, уточнение DDL) поднял качество до эталонного, а замена инференс-фреймворка на vLLM сократила генерацию SQL с двух минут до трёх секунд.
Вывод из кейса для всех: генерировать SQL локально — рабочий сценарий, а не экзотика, и данные остаются в компании.
Кейс 2: агент, который нашёл data-loss баг в базе
Саймон Уиллисон, известный автор о данных и инструментах, описал на simonwillison.net (5 июля 2026) подготовку релиза своей библиотеки sqlite-utils — утилиты для работы с SQLite. За 37 промптов и 34 коммита агент (Claude) внёс +1321/−190 строк в 30 файлов и — главное — нашёл перед релизом критический баг:
delete_where()never commits and poisons the connection (data loss). Table.delete_where() runs its DELETE via a bare self.db.execute() with no atomic() wrapper. The connection is left in_transaction=True, so every subsequent atomic() call takes the savepoint branch and never commits either.
Перевод: delete_where() не завершал транзакцию, соединение оставалось в состоянии in_transaction, и все последующие записи молча откатывались при закрытии базы. Пользователь видел удалённые строки, а на диске их не было. Без ревью агентом баг уехал бы в релиз.
Стоимость работы — по оценке через инструмент AgentsView — $149,25 (основная сессия $141,02). Второй раунд ревью провела уже другая модель (GPT-5.5), и она нашла ещё две проблемы уровня P1. Уиллисон резюмирует: «я начал по привычке просить лучшую модель Anthropic ревьюить работу OpenAI и наоборот — это стабильно приносит интересные результаты».
Кейс показателен для темы ИИ и баз данных: агент не только генерировал код для работы с БД, но и проверял его на соответствие документации, находил потерю данных — и это спасло релиз.
Безопасность: главное правило — не давать агенту права на прод
База данных — не файлы проекта: ошибка здесь означает потерю или утечку чужих данных. Правила на момент публикации:
- Read-only пользователь. В строке подключения — отдельный пользователь без прав на запись (
readonly). Это первая и главная защита, её рекомендует сама документация Claude Code. - Режим restricted у сервера. Postgres MCP Pro в restricted-режиме выполняет только чтение и ограничивает время запроса; reference-сервер PostgreSQL изначально работает внутри транзакции READ ONLY.
- Парсер SQL. Сервер отклоняет конструкции, которые ломают read-only:
COMMIT,ROLLBACK, DDL. Агент может попытаться обойти транзакцию запросомROLLBACK; DROP TABLE users;— парсер pglast это режет. - Копия вместо прода. Для экспериментов используйте dev-копию базы или синтетические данные — так сделали в ecom.tech.
- Лимиты. Ограничение числа строк в ответе и таймаут запроса защищают базу от тяжёлых
SELECTбез LIMIT, которые агент может написать по незнанию. - Подтверждение вызовов. В интерфейсах агентов каждый вызов инструмента должен быть виден и подтверждаться человеком. Не запускайте агента в автоматическом режиме с полным доступом к базе без присмотра.
Типовые ошибки: галлюцинации имён колонок
Самая частая ошибка ИИ при работе с БД — выдуманные имена таблиц и колонок. Модель видела в обучении похожие схемы и «вспоминает» колонку, которой нет. База отвечает ошибкой ERROR 42703: column "total_revenue" does not exist — если запрос вообще запустился.
Как защититься:
- Схема в промпте обязательна. DDL или список таблиц с колонками — даже для простого запроса.
- Включите инструмент поиска по схеме. У DBHub это
search_objects, у reference-сервера — ресурсы со схемой таблиц. Агент смотрит фактические имена перед тем, как писать запрос. - Прогоняйте на тестовой копии. Ошибка 42703 — не страшно, если запрос упал в изолированной базе. На проде такая ошибка ничего не сломает, а вот
DELETEбезWHERE— может. - Проверяйте результат глазами. Цифра правдоподобна ≠ цифра верна. Агент может «согласиться» с неверным результатом — критерий проверки должен задать человек.
Про другие грабли агентской работы (потеря контекста, «правдоподобный» код) — в статье про агентный кодинг.
Российские реалии
Локальные базы данных — без VPN и без оплаты. PostgreSQL в Docker или SQLite работают локально, и для них не нужны ни VPN, ни зарубежные карты. Если хочется полностью автономную связку, локальную модель (например, Qwen3-Coder через Ollama) подключают к агенту вместо облачной — такой сценарий разобран в нашей статье. Опыт генерации SQL на локальных моделях в российском контуре есть у ecom.tech (Хабр, февраль 2026).
MCP — открытый протокол. Реестры и документация из России открываются без ограничений; сам факт работы из РФ для MCP-серверов не важен — важно, где находится ваша база.
Supabase. Облачный PostgreSQL (open source BaaS) из России доступен без VPN, судя по свежим кейсам — например, автор с Хабра собрал на Supabase + Cloudflare Workers новостной агрегатор и подробно описал, что пошло не так (Хабр, июнь 2026). Бесплатный тариф (500 МБ базы, 2 проекта, 50 тыс. активных пользователей, supabase.com/pricing) регистрации с картой не требует. Платная подписка Pro от $25/мес — оплата зарубежной картой (российские Visa/Mastercard не проходят; Mir и UnionPay Supabase не принимает; вариант — карта зарубежного банка или посредник). Публичного пошагового гайда «как оплатить Supabase из РФ» в рунете на момент публикации не нашлось — проверяйте свежие кейсы на Хабре перед оплатой.
Neon. Serverless PostgreSQL с ветками и scale-to-zero. Из России доступен; бесплатный тариф — 0,5 ГБ хранилища и 100 CU-часов в месяц на проект, карта не нужна (neon.tech/pricing). Платный Launch — pay-as-you-go: $0,106 за CU-час и $0,35 за ГБ-месяц, тоже зарубежная карта. Русскоязычный опыт работы с Neon есть: на Хабре разобраны четыре production-инцидента с advisory locks на Neon (май 2026). Русскоязычных обзоров «Neon из России» в духе «работает без VPN» мало — общий вывод по доступности сделан по прямым проверкам сайта и свежим кейсам.
Если коротко: для старта из РФ самый беспроблемный путь — локальный Postgres (или SQLite) + агент с MCP-сервером; облачные Supabase/Neon годятся для пет-проектов на бесплатных тарифах, а платная часть упирается в зарубежную карту.
Советы
- Начинайте с генерации без доступа к базе. Схема в промпте + SQL в ответе — нулевой риск, и этого достаточно для 80% задач.
- Подключайте MCP-сервер, когда нужно выполнять запросы. Для отладки и аналитики агент с read-only доступом экономит часы.
- Один сервер — один круг задач. Не вешайте на агента одновременно прод-базу и файлы проекта с секретами.
- Фиксируйте критерий «правильно». Для SQL это: ожидаемая цифра, набор тестовых данных, выполнение на копии базы.
- Локальные модели — рабочий вариант. Если данные нельзя отдавать наружу, text2SQL на локальной модели реально работает (кейс ecom.tech).
Честные ограничения
- Галлюцинации не исчезают со схемой. Схема убирает ошибки имён, но не гарантирует бизнес-корректность: агент может сгенерировать валидный SQL с неверной логикой. Проверка — за человеком.
- Агент не знает ваши данные. Он видит схему, а не смысл строк. Запрос к продакшену с плохим
WHEREможет вернуть неверные цифры, которые легко принять за верные. - Стоимость. Автономные агентские сессии (кейс Уиллисона) легко съедают десятки долларов на ревью релиза; для разовых SQL-запросов дешевле просто сгенерировать запрос в чате.
- SQLite/Postgres — не вся картина. Для NoSQL, огромных кластеров и специфических диалектов возможности агентов уже, а проверить запрос на копии сложнее.
- Версии движутся быстро. Команды и серверы актуальны на август 2026 года; перед внедрением сверяйтесь с документацией агента и реестром MCP.
Вывод
ИИ для баз данных в 2026 году — это не «вставьте задачу и получите идеальный запрос», а рабочий инструмент с понятными правилами: дайте схеме, подключите агента к базе через MCP-сервер с read-only доступом, прогоняйте на копии и проверяйте результат человеком. Генерация SQL экономит время уже сейчас, агенты с доступом к базе закрывают аналитику и отладку, а локальные модели решают вопрос приватности данных. Начните с малого: один MCP-сервер, одна база, read-only пользователь — и смотрите, где агенту можно доверять, а где нужен контроль.
Дальше по теме: что такое MCP, лучшие MCP-серверы, как установить Claude Code, как установить OpenCode, локальные нейросети для кодинга: Qwen3-Coder через Ollama.