📘 DataGate — Puerta de enlace de datos segura y lista para IA

DataGate es una puerta de enlace headless, segura y basada en políticas que expone bases de datos a herramientas de IA (como GitHub Copilot) de forma controlada, predecible y sin SQL libre.

DataGate actúa como intermediario entre un LLM y una base de datos real: no permite acceso directo a la base de datos, no expone consultas arbitrarias, no permite operaciones de escritura. Está diseñado para ser de solo lectura, consciente del esquema, multibase de datos y completamente seguro para LLM.

🎯 Objetivos principales

• Acceso seguro a los datos — solo lectura garantizada mediante roles de base de datos, motor de políticas y constructor de consultas controlado.

• Abstracción de la base de datos — el modelo no genera SQL: DataGate construye consultas seguras y validadas.

• Multibase de datos — puede conectarse a diferentes bases de datos de diferentes aplicaciones, como un DBeaver headless.

• Motor de políticas — control granular sobre tablas, columnas, filtros, límites y complejidad de las operaciones.

• Conocimiento del esquema — carga automáticamente el esquema de la base de datos y aplica reglas de seguridad.

• Concurrencia real — arquitectura asíncrona y segura, ideal para solicitudes paralelas desde Copilot.

• Métricas y auditoría — seguimiento de solicitudes, tiempos, errores y límites para depuración y observabilidad.

• Perfilado de rendimiento — perfil de latencia en proceso (mín/med/p50/p95/p99/máx) para monitoreo de la evolución del rendimiento.

• Backend abstracto — trait de solo lectura común para backends de bases de datos, con implementaciones concretas para PostgreSQL, MySQL/MariaDB y SQLite.

Related MCP server: DB MCP Gateway

🧩 Características principales

• Constructor de consultas controlado — operaciones semánticas como select, search, aggregate, con validación automática.

• MCP select tipado — contrato JSON, ejecución de solo lectura con filas JSON, políticas, auditoría y errores saneados; el transporte MCP sigue siendo el siguiente paso.

• MCP search tipado — búsqueda semántica con ILIKE sobre columnas permitidas, consultas parametrizadas, políticas/límite de tasa/métricas/auditoría y salida limitada en el servidor.

• MCP aggregate tipado — count, sum, avg, min y max sobre columnas permitidas, con filtros parametrizados y sin soporte para SQL libre o GROUP BY.

• API MCP versionada — descriptor estable para versión de API y herramientas disponibles.

• Transporte MCP stdio — handshake, descubrimiento y llamadas select, search y aggregate sobre la ruta segura por políticas.

• Filtros avanzados — soporte para patrones (LIKE/ILIKE), rangos (BETWEEN) y texto completo (to_tsvector + plainto_tsquery) siempre parametrizados y validados por políticas.

• Catálogo de esquema controlado — introspección filtrada por políticas de tablas, vistas, índices, restricciones (PK/FK/CHECK/UNIQUE/EXCLUSION), disparadores, funciones, procedimientos y secuencias; definiciones DDL solo cuando es seguro.

• Límite de tasa — protección contra bucles del modelo y consultas demasiado pesadas.

• Límites de salida — respuestas siempre contenidas, seguras y estructuradas.

• Errores deterministas — sin fugas de esquema, sin SQL expuesto, sin stack trace.

• Errores estructurados — envoltura estable con código, mensaje genérico e indicación retryable.

• Configuración externa — archivo TOML para políticas, límites y perfiles nombrados (dev/staging/prod).

• Endurecimiento de entrada MCP — validación de request_id, límites en cargas útiles de texto y cardinalidad para reducir superficies de ataque DoS/abuso de entrada.

• Política dinámica — la política activa puede reemplazarse atómicamente, incluso recargándola desde TOML, sin recrear las herramientas MCP.

DataGate no expone una función MCP de consulta SQL libre: el agente envía exclusivamente parámetros estructurados, validados contra el esquema y las políticas antes de la construcción de la consulta parametrizada.

Los errores públicos usan los códigos invalid_request, policy_denied, backend_unavailable e internal_error. SQL, stack traces, contraseñas, valores de filtros y nombres de objetos no autorizados no cruzan el límite MCP.

Configuración de PostgreSQL

Las credenciales de PostgreSQL no se guardan en archivos de configuración ni en el código. El servicio lee la conexión desde el entorno de ejecución:

• modo compacto: DB_URL

• modo por componentes: DB_HOST, DB_PORT (predeterminado 5432), DB_USER, DB_PASSWORD, DB_NAME

• opciones de PostgreSQL: DB_OPTIONS, en el formato key=value&key=value

• pool: DB_MAX_CONNECTIONS y DB_ACQUIRE_TIMEOUT_SECS

Configuración de SQLite

Para usar SQLite en modo de solo lectura, configura una de las dos variantes:

• URL completa: SQLITE_URL

• ruta de archivo: SQLITE_PATH

Opciones del pool de SQLite:

• SQLITE_MAX_CONNECTIONS

• SQLITE_ACQUIRE_TIMEOUT_SECS

Configuración de MySQL/MariaDB

Para usar MySQL o MariaDB en modo de solo lectura, configura una de las dos variantes:

• URL completa: MYSQL_URL

• modo por componentes: MYSQL_HOST, MYSQL_PORT (predeterminado 3306), MYSQL_USER, MYSQL_PASSWORD, MYSQL_DATABASE

Opciones del pool de MySQL/MariaDB:

• MYSQL_MAX_CONNECTIONS

• MYSQL_ACQUIRE_TIMEOUT_SECS

Selección de backend multibase de datos

Para elegir explícitamente qué backend activar, establece DATAGATE_BACKEND:

• auto (predeterminado): precedencia postgres -> mysql -> sqlite

• postgres

• mysql (o mariadb)

• sqlite

Cuando DATAGATE_BACKEND se establece en un backend específico, DataGate requiere la configuración de entorno correspondiente; de lo contrario, termina con un error explícito.

Precedencia del backend en el arranque:

1. PostgreSQL

2. MySQL/MariaDB

3. SQLite

El primer backend configurado en la lista se activa.

El límite de tasa opcional del lado del servidor usa RATE_LIMIT_REQUESTS y RATE_LIMIT_WINDOW_SECS. El límite se aplica por request_id antes de las políticas, el constructor de consultas y la base de datos; las solicitudes que superan el umbral reciben rate_limited y no generan SQL.

El constructor de consultas también aplica un presupuesto máximo configurable en la política mediante max_query_complexity: cada columna cuesta 1 y cada filtro cuesta 2. Las solicitudes que superan el presupuesto se rechazan antes de generar SQL.

La respuesta select también está sujeta a max_output_bytes en la política: si la carga útil JSON final supera el límite, DataGate rechaza la solicitud con un error de política sin exponer SQL ni detalles internos.

La capa de métricas también registra contadores y latencia del lado del servidor para la herramienta select: solicitudes totales/aceptadas/rechazadas, errores de backend, latencia p95 en memoria y instantánea del pool de PostgreSQL (size, idle).

El registro de aplicaciones admite dos formatos:

• LOG_FORMAT=pretty (predeterminado)

• LOG_FORMAT=json (estructurado, adecuado para recolectores de registros)

El nivel mínimo de registro se puede configurar con LOG_LEVEL (trace|debug|info|warn|error) o mediante RUST_LOG.

Si DB_URL está presente, tiene precedencia sobre los componentes. El rol de PostgreSQL debe tener solo permisos de lectura; además, cada conexión establece default_transaction_read_only = on.

El perfil activo se selecciona con profile = "dev" y puede definir la política en [profiles.dev.policy]. Si no hay perfiles nombrados, se sigue admitiendo la forma heredada [policy]. Un perfil declarado pero inexistente activa una política de denegación total, sin iniciar operaciones en la base de datos.

Las versiones publicadas incluyen binarios para Linux x64/ARM64, Windows x64/ARM64 y macOS Intel/Apple Silicon, con archivos nombrados por plataforma y archivos SHA256SUMS-* para la verificación de los artefactos.

🛡️ ¿Por qué DataGate?

Los LLM no deben hablar directamente con las bases de datos. Se necesita una capa segura, predecible, controlada, auditable, extensible y multiaplicación. DataGate es esa capa.

🔧 Tecnologías

• Lenguaje: Rust

• Bases de datos: PostgreSQL, MySQL/MariaDB y SQLite (hoy), otras bases de datos mañana

• Protocolo: MCP (Model Context Protocol)

• Arquitectura: asíncrona, basada en políticas, consciente del esquema

🚀 Estado del proyecto

DataGate está en fase de diseño. El repositorio contiene la estructura inicial, la documentación y la hoja de ruta técnica.

🧪 Pruebas de integración multibackend

Las pruebas de integración de backend usan variables de entorno opcionales:

• DATAGATE_TEST_POSTGRES_URL

• DATAGATE_TEST_MYSQL_URL

Cuando una variable está presente, la prueba correspondiente verifica que el backend de solo lectura ejecute SELECT controladas y rechace sentencias de escritura. Si la variable no está presente, la prueba se omite sin error.

Documentación completa:

• Architecture.md — principios de diseño y arquitectura por capas

• ROADMAP.md — hoja de ruta detallada hacia la 1.0

• docs/configuration.md — inicio rápido, backend, políticas y operaciones

• docs/benchmarks.md — benchmarks locales de SQLite y PostgreSQL real

• docs/hardening.md — lista de verificación de endurecimiento final para el límite MCP/base de datos

• docs/http-transport-decision.md — decisión de seguridad sobre el transporte MCP HTTP remoto

• docs/editor-registry-evaluation.md — evaluación de requisitos del registro MCP y clientes entre editores

• docs/packaging.md — canales de empaquetado y fuente canónica de los artefactos

• docs/postgres-mcp-comparison.md — comparación con otros servidores MCP de PostgreSQL

• docs/registry-publication.md — estrategia del registro MCP, instalación entre editores y conexiones nombradas

• docs/mcp-registry-metadata.json — metadatos candidatos para registros/galerías MCP

• docs/release-candidate.md — criterios y puertas de la candidata 1.0

• docs/mcp-tools.md — contratos internos y reglas de las herramientas MCP

• CONTRIBUTING.md — reglas de contribución, commits y ramas

• SECURITY.md — política de seguridad y notificación de vulnerabilidades

Para el inicio desde VS Code con MCP:

• el transporte local predeterminado es stdio

• las plantillas mcp.json para stdio local están en docs/mcp-tools.md y docs/configuration.md

• HTTP remoto está fuera del predeterminado 1.0 y requiere una decisión de seguridad dedicada

📍 Hoja de ruta (resumen)

• Definición del motor de políticas

• Implementación del constructor de consultas controlado (select parametrizado)

• Conexión de solo lectura garantizada

• Conocimiento automático del esquema (catálogo interno de PostgreSQL)

• Base de registro de auditoría (JSONL mediante AUDIT_LOG_PATH)

• Herramientas MCP (select, search, aggregate)

• Soporte multibase de datos (PostgreSQL, MySQL/MariaDB, SQLite)

• Capa empresarial inicial (observabilidad, endurecimiento, política dinámica)

• Estabilidad de la API MCP (descriptor versionado; transporte stdio)

• Transporte MCP stdio

• Benchmarks

• Endurecimiento final

• Candidata a versión 1.0

📄 Licencia

Licencia Apache 2.0