Skip to main content
Glama

📘 DataGate — Безопасный AI-готовый шлюз данных

Build Release License

DataGate — это headless-шлюз, безопасный и управляемый политиками, который предоставляет доступ к базам данных для AI-инструментов (например, GitHub Copilot) контролируемым, предсказуемым образом и без свободного SQL.

DataGate выступает в роли посредника между LLM и реальной базой данных: он не допускает прямого доступа к базе данных, не предоставляет произвольные запросы и не разрешает операции записи. Он спроектирован как read-only, schema-aware, multi-database и полностью LLM-safe.

🎯 Основные цели

  • Безопасный доступ к данным — гарантированный read-only через роли БД, policy engine и контролируемый query builder.

  • Абстракция базы данных — модель не генерирует SQL: DataGate строит безопасные и проверенные запросы.

  • Multi-database — может подключаться к различным базам данных разных приложений, как headless DBeaver.

  • Policy engine — детальный контроль над таблицами, колонками, фильтрами, лимитами и сложностью операций.

  • Schema awareness — автоматическая загрузка схемы базы данных и применение правил безопасности.

  • Реальная конкурентность — асинхронная и безопасная архитектура, идеальна для параллельных запросов от Copilot.

  • Метрики и аудит — отслеживание запросов, времени, ошибок и лимитов для отладки и наблюдаемости.

  • Профилирование производительности — профиль задержки in-process (min/avg/p50/p95/p99/max) для эволюционного мониторинга производительности.

  • Абстрактный бэкенд — общий read-only trait для бэкендов баз данных с конкретными реализациями для PostgreSQL, MySQL/MariaDB и SQLite.

Related MCP server: MCP DB Gateway

🧩 Основные функции

  • Контролируемый query builder — семантические операции, такие как select, search, aggregate, с автоматической валидацией.

  • Типизированный MCP select — JSON-контракт, read-only выполнение с JSON-строками, политики, аудит и санитизированные ошибки; транспорт MCP остаётся следующим шагом.

  • Типизированный MCP search — семантический поиск с ILIKE по разрешённым колонкам, параметризованные запросы, политики/rate-limit/метрики/аудит и ограничение вывода на стороне сервера.

  • Типизированный MCP aggregate — count, sum, avg, min и max по разрешённым колонкам, с параметризованными фильтрами и без поддержки свободного SQL или GROUP BY.

  • Версионированное MCP API — стабильный дескриптор для версии API и доступных инструментов.

  • Транспорт MCP stdio — handshake, обнаружение и вызовы select, search и aggregate через policy-safe путь.

  • Расширенные фильтры — поддержка шаблонов (LIKE/ILIKE), диапазонов (BETWEEN) и полнотекстового поиска (to_tsvector + plainto_tsquery), всегда параметризованных и проверяемых политиками.

  • Контролируемый каталог схемы — интроспекция с фильтрацией по политикам таблиц, представлений, индексов, ограничений (PK/FK/UNIQUE/CHECK/EXCLUSION), триггеров, функций, процедур и последовательностей; определения DDL только когда безопасно.

  • Rate limiting — защита от циклов модели и слишком тяжёлых запросов.

  • Лимиты вывода — ответы всегда ограничены, безопасны и структурированы.

  • Детерминированные ошибки — никакой утечки схемы, никакого раскрытия SQL, никаких stack trace.

  • Структурированные ошибки — стабильная обёртка с кодом, общим сообщением и указанием retryable.

  • Внешняя конфигурация — TOML-файлы для политик, лимитов и именованных профилей (dev/staging/prod).

  • Усиление ввода MCP — валидация request_id, лимиты на текстовые полезные нагрузки и кардинальность для снижения поверхностей DoS/злоупотребления вводом.

  • Динамическая политика — активная политика может быть атомарно заменена, в том числе перезагружена из TOML, без пересоздания MCP-инструментов.

DataGate не предоставляет MCP-функцию свободного SQL-запроса: агент отправляет исключительно структурированные параметры, проверяемые по схеме и политике перед построением параметризованного запроса.

Публичные ошибки используют коды invalid_request, policy_denied, backend_unavailable и internal_error. SQL, stack trace, пароли, значения фильтров и имена неавторизованных объектов не пересекают границу MCP.

Конфигурация PostgreSQL

Учётные данные PostgreSQL не сохраняются в файлах конфигурации или в коде. Сервис читает подключение из окружения времени выполнения:

  • компактный режим: DB_URL

  • режим компонентов: DB_HOST, DB_PORT (по умолчанию 5432), DB_USER, DB_PASSWORD, DB_NAME

  • опции PostgreSQL: DB_OPTIONS, в формате key=value&key=value

  • пул: DB_MAX_CONNECTIONS и DB_ACQUIRE_TIMEOUT_SECS

Конфигурация SQLite

Для использования SQLite в режиме read-only настройте один из двух вариантов:

  • полный URL: SQLITE_URL

  • путь к файлу: SQLITE_PATH

Опции пула SQLite:

  • SQLITE_MAX_CONNECTIONS

  • SQLITE_ACQUIRE_TIMEOUT_SECS

Конфигурация MySQL/MariaDB

Для использования MySQL или MariaDB в режиме read-only настройте один из двух вариантов:

  • полный URL: MYSQL_URL

  • режим компонентов: MYSQL_HOST, MYSQL_PORT (по умолчанию 3306), MYSQL_USER, MYSQL_PASSWORD, MYSQL_DATABASE

Опции пула MySQL/MariaDB:

  • MYSQL_MAX_CONNECTIONS

  • MYSQL_ACQUIRE_TIMEOUT_SECS

Выбор multi-database бэкенда

Чтобы явно выбрать, какой бэкенд активировать, установите DATAGATE_BACKEND:

  • auto (по умолчанию): приоритет postgres -> mysql -> sqlite

  • postgres

  • mysql (или mariadb)

  • sqlite

Когда DATAGATE_BACKEND установлен на конкретный бэкенд, DataGate требует соответствующую конфигурацию окружения; в противном случае завершается с явной ошибкой.

Приоритет бэкенда при загрузке:

  1. PostgreSQL

  2. MySQL/MariaDB

  3. SQLite

Активируется первый настроенный бэкенд из списка.

Необязательный серверный rate limiting использует RATE_LIMIT_REQUESTS и RATE_LIMIT_WINDOW_SECS. Лимит применяется к request_id до политики, query builder и базы данных; запросы сверх порога получают rate_limited и не генерируют SQL.

Query builder также применяет максимальный бюджет, настраиваемый в политике через max_query_complexity: каждая колонка стоит 1, каждый фильтр стоит 2. Запросы сверх бюджета отклоняются до генерации SQL.

Ответ select также подчиняется max_output_bytes в политике: если итоговая JSON-полезная нагрузка превышает лимит, DataGate отклоняет запрос с ошибкой политики, не раскрывая SQL или внутренние детали.

Слой метрик также регистрирует счётчики и задержку на стороне сервера для инструмента select: всего запросов/принято/отклонено, ошибки бэкенда, p95 задержка в памяти и снимок пула PostgreSQL (size, idle).

Логирование приложения поддерживает два формата:

  • LOG_FORMAT=pretty (по умолчанию)

  • LOG_FORMAT=json (структурированный, подходит для сборщиков логов)

Минимальный уровень логов можно настроить с помощью LOG_LEVEL (trace|debug|info|warn|error) или через RUST_LOG.

Если DB_URL присутствует, он имеет приоритет над компонентами. Роль PostgreSQL должна иметь только права на чтение; кроме того, каждое подключение устанавливает default_transaction_read_only = on.

Активный профиль выбирается с помощью profile = "dev" и может определять политику в [profiles.dev.policy]. Если именованные профили отсутствуют, поддерживается устаревшая форма [policy]. Объявленный, но несуществующий профиль активирует политику deny-all, не запуская операции с базой данных.

Опубликованные релизы включают бинарники для Linux x64/ARM64, Windows x64/ARM64 и macOS Intel/Apple Silicon, с архивами, названными по платформе, и файлами SHA256SUMS-* для проверки артефактов.

🛡️ Почему DataGate?

LLM не должны напрямую общаться с базами данных. Нужен безопасный, предсказуемый, контролируемый, аудируемый, расширяемый и мульти-приложенческий слой. DataGate — это такой слой.

🔧 Технологии

  • Язык: Rust

  • Базы данных: PostgreSQL, MySQL/MariaDB и SQLite (сегодня), другие БД завтра

  • Протокол: MCP (Model Context Protocol)

  • Архитектура: асинхронная, управляемая политиками, schema-aware

🚀 Статус проекта

DataGate находится на стадии проектирования. Репозиторий содержит начальную структуру, документацию и техническую дорожную карту.

🧪 Тесты интеграции multi-backend

Тесты интеграции бэкендов используют необязательные переменные окружения:

  • DATAGATE_TEST_POSTGRES_URL

  • DATAGATE_TEST_MYSQL_URL

Когда переменная присутствует, соответствующий тест проверяет, что read-only бэкенд выполняет контролируемые SELECT и отклоняет операторы записи. Если переменная отсутствует, тест пропускается без ошибки.

Полная документация:

  • Architecture.md — принципы проектирования и слоистая архитектура

  • ROADMAP.md — подробная дорожная карта к версии 1.0

  • docs/configuration.md — quick start, бэкенды, политики и операции

  • docs/benchmarks.md — локальные бенчмарки SQLite и реального PostgreSQL

  • docs/hardening.md — финальный чек-лист усиления для границы MCP/база данных

  • docs/http-transport-decision.md — решение по безопасности для удалённого MCP HTTP транспорта

  • docs/editor-registry-evaluation.md — оценка требований MCP Registry и кросс-редакторных клиентов

  • docs/packaging.md — каналы упаковки и канонический источник артефактов

  • docs/postgres-mcp-comparison.md — сравнение с другими MCP-серверами PostgreSQL

  • docs/registry-publication.md — стратегия MCP Registry, кросс-редакторная установка и именованные подключения

  • docs/mcp-registry-metadata.json — кандидат метаданных для реестров/галерей MCP

  • docs/release-candidate.md — критерии и ворота кандидата 1.0

  • docs/mcp-tools.md — внутренние контракты и правила MCP-инструментов

  • CONTRIBUTING.md — правила внесения вклада, коммитов и веток

  • SECURITY.md — политика безопасности и сообщение об уязвимостях

Для запуска из VS Code с MCP:

  • локальный транспорт по умолчанию — stdio

  • шаблоны mcp.json для локального stdio находятся в docs/mcp-tools.md и docs/configuration.md

  • удалённый HTTP не входит в дефолт 1.0 и требует отдельного решения по безопасности

📍 Дорожная карта (кратко)

  • Определение policy engine

  • Реализация контролируемого query builder (параметризованный select)

  • Гарантированное read-only подключение

  • Автоматическая schema awareness (внутренний каталог PostgreSQL)

  • Основа аудит-лога (JSONL через AUDIT_LOG_PATH)

  • MCP-инструменты (select, search, aggregate)

  • Поддержка multi-database (PostgreSQL, MySQL/MariaDB, SQLite)

  • Начальный enterprise-слой (наблюдаемость, усиление, динамическая политика)

  • Стабильность MCP API (версионированный дескриптор; транспорт stdio)

  • Транспорт MCP stdio

  • Бенчмарки

  • Финальное усиление

  • Кандидат версии 1.0

📄 Лицензия

Apache License 2.0

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Provides read-only access to databases for MCP-compatible AI tools, allowing schema exploration and SELECT queries without exposing credentials or risking data changes.
    101 npm
    3
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Provides governed, read-only PostgreSQL access for AI agents via MCP. Enforces schema/table allowlists, query limits, and audit events.
    1
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Provides read-only, guarded access to business databases via MCP. Enables natural language querying with built-in security barriers like table allowlists, PII masking, and audit logging.
    MIT
  • F
    license
    Not graded
    quality
    B
    maintenance
    Enables secure, read-only querying of only predefined logical database views through MCP tools and a REST API, using validated SQL and semantic view metadata.
    -