SchemaGate filtra el esquema por identidad antes de que el modelo escriba la consulta
La librería open source decide qué tablas ve el modelo de text-to-SQL según quién pregunta, en lugar de validar permisos después de generar el SQL.
Casi todos los stacks de text-to-SQL hacen lo mismo: le meten el esquema entero al modelo y comprueban los permisos cuando la consulta ya está escrita. SchemaGate, una librería publicada bajo Apache-2.0, invierte ese orden. Filtra el catálogo por la identidad de quien pregunta y solo entonces deja trabajar al modelo, de forma que las tablas a las que ese llamante no tiene acceso no llegan nunca al prompt.
El proyecto sostiene que el orden es justamente el fallo, y lo enseña con dos ejemplos sobre esquemas reales antes de pedir que le creas.
Dos llamantes, la misma pregunta
En un esquema de recursos humanos, un llamante sin roles provoca que se seleccionen 9 de 42 objetos y que el prompt ocupe 570 tokens en vez de 2.511. Un objeto queda fuera de su vista. Cambia la identidad, no la pregunta: el mismo esquema con un llamante que tiene el rol de nóminas coloca hr_compensation como primera tabla del prompt y no oculta nada.
El segundo caso es un esquema de siniestros. Ahí salen 14 de 51 objetos y 1.212 tokens frente a 3.237, con tres objetos retenidos porque ese llamante no tiene ni actuarial ni phi. Los que se quedan fuera aparecen listados, así que se ve qué se ha filtrado en lugar de suponerlo.
La instalación es un pip install schemagate. La herramienta está certificada contra instancias vivas de SQLite, PostgreSQL 16, Oracle 26ai, SQL Server 2022 y MySQL 8.4. Además del paquete hay un servidor MCP, ya en el registro oficial de MCP, un retriever para LangChain y una CLI. Todo el código está en el repositorio.
El paso de recuperación no es el mejor del mercado
Aquí viene la parte que no suele aparecer en un lanzamiento. El autor reconoce que su selección de esquemas no es estado del arte. Sobre Spider agrupado en un único catálogo de 876 tablas, sin pista de a qué base de datos pertenece cada pregunta, todas las tablas gold están presentes el 82,6% de las veces en el top 10. En Spider 2.0-lite, que usa esquemas reales de BigQuery y Snowflake en lugar de los del benchmark, la cifra baja al 64,0% en el top 10 sobre las 247 preguntas utilizables.
Los dos números, el harness de medición y los dos errores de medida que hubo que corregir por el camino están publicados en BENCHMARKS.md.
Que el filtrado del esquema y el control de acceso vayan en la misma capa tiene sentido operativo: si un rol no debe ver una tabla, el modelo no debería verla tampoco. Menos objetos significa menos tokens y menos ruido en el contexto, y el principio de mínimo privilegio se aplica antes de la generación, no como validación a posteriori. Quien tenga text-to-SQL montado sobre bases de datos con información sensible sabe que esto se resuelve hoy a base de parches en el prompt y listas de tablas permitidas. Queda por ver cómo se comporta la selección cuando el catálogo crece mucho más allá de esas 876 tablas.
