IA nativa
IA nativa en Postgres: NL2SQL, RAG y agentes
NL2SQL y RAG integrados directamente en el backend de Aurabase, no se agregaron conectores externos como una ocurrencia tardía. Desglosando precisamente lo que significa "nativo", capacidad por capacidad.
Aurabase incrusta NL2SQL (lenguaje natural a SQL, validado y acotado) y trapo (búsqueda de pgvector, incrustaciones HNSW) directamente en el backend, con 3 proveedores nativos de LLM (OpenAI, Antrópico/Claude, Géminis). Mistral, Scaleway AI y Ollama siguen siendo accesibles a través de un punto final compatible con OpenAI, en lugar de un cliente nativo personalizado.
NL2SQL: un mensaje en lenguaje natural y salida SQL segura
El motor NL2SQL de Aurabase valida cada consulta generada antes de su ejecución: análisis AST mediante analizador sql, una lista estricta de funciones SQL permitidas y un límite LÍMITE aplicado en cada consulta ejecutada. Esta no es una llamada LLM sin restricciones: es un validador de sintaxis estricto que niega cualquier cosa más allá de una simple SELECCIONAR.
El validador rechaza explícitamente cláusulas CTE/WITH, subconsultas, declaraciones UNION y funciones no incluidas en la lista blanca (contar, suma, promedio, mín., máximo, inferior, superior, fusionarse, fecha_trunc, ahora) y cualquier acceso al catálogo del sistema. El límite de filas se puede configurar en el lado del servidor y se puede restringir por consulta, nunca expandirse más allá del límite de inquilinos.
RAG y pgvector nativos: cero dependencias externas
pgvector 0.8.6 está preinstalado en cada imagen de Postgres del inquilino de Aurabase, junto con una canalización de ingesta que presenta reintentos automáticos de red y búsqueda de vectores HNSW en 3 clases de dimensiones (768, 1536 y 3072), muy dentro del límite de 16 000 dimensiones de pgvector.
No hay pasos adicionales para "instalar" pgvector: la extensión está integrada en la imagen estándar del inquilino. La canalización de ingesta en sí es una capacidad a nivel de aplicación diseñada directamente en Aurabase.
El almacenamiento está estructurado por espacio de nombres: cada documento ingerido (POST /v1/ai/ /rag/ingest) se fragmenta, se incrusta y se asigna a la columna de dimensión vectorial coincidente. El punto final de la consulta (POST /v1/ai/ /rag/query) combina recuperación y generación; un punto final dedicado (OBTENER /v1/ai/ /búsqueda) expone la búsqueda de similitud de vectores por sí sola, sin activar una llamada LLM. Cambiar los modelos de incrustación nunca rompe su conjunto de datos: un espacio de nombres se puede volver a indexar (POST /v1/ai/ /rag/ /reindexar) bajo un nuevo modelo sin volver a cargar documentos.
Matices técnicos rara vez documentados en otros lugares: más allá de 2000 dimensiones, HNSW no puede indexar el estándar de pgvector vector tipo. Para 3072 dimensiones, Aurabase aprovecha automáticamente mediovec(3072) (precisión reducida, indexable) en lugar de degradar silenciosamente las consultas en escaneos completos de la tabla. De forma predeterminada, la recuperación devuelve 5 pasajes (top_k) por encima de un umbral de similitud de 0,3: ambos parámetros se pueden anular por consulta.
3 proveedores nativos y lo que excluye "nativo"
OpenAI, Anthropic (Claude) y Google Gemini tienen integraciones de clientes nativos dedicados dentro del código base de Aurabase. Mistral, Scaleway AI y Ollama siguen siendo accesibles a través de un punto final compatible con OpenAI, una distinción operativa importante si su pila depende de primitivas de proveedores personalizadas.
| Proveedor | Integración | Impacto |
|---|---|---|
| Abierto AI | Dedicated native client | Direct project API key configuration |
| Antrópico (Claude) | Dedicated native client | Direct project API key configuration |
| Google Géminis | Dedicated native client | Direct project API key configuration |
| mistral | OpenAI-compatible endpoint | Functional via standard endpoint, without custom client |
| IA de escala | OpenAI-compatible endpoint | Functional via standard endpoint, without custom client |
| Ollama (autohospedado) | OpenAI-compatible endpoint | Ideal para LLM locales o implementaciones locales |
Por qué Supabase apuesta por conectores en lugar de NL2SQL nativo
Supabase lanzó un conector Claude oficial en febrero de 2026, seguido de una integración ChatGPT. Ambos permiten consultar una base de datos Supabase desde una interfaz de chat de terceros: un patrón de orquestación externo, claramente diferente de un motor NL2SQL integrado directamente en el backend. Vea también nuestro Comparación completa de Aurabase vs Supabase.
¿Qué impide que un LLM ejecute consultas arbitrarias o destructivas?
Se aplican tres medidas de seguridad antes de cualquier ejecución: validación de sintaxis estricta (solo SELECT, lista de funciones permitidas), límite de resultados limitado mediante LIMIT y aislamiento del esquema de destino únicamente al proyecto que realiza la llamada. El cliente nunca proporciona el esquema introspeccionado: se origina en la base de datos del proyecto, la única fuente autorizada.
SELECCIONAR consultas. Cualquier intento de INSERTAR, ACTUALIZAR, BORRAR, CAÍDA, CREAR, o ALTERAR emitido por el modelo se rechaza en el nivel AST, antes de la ejecución, no simplemente mediante una instrucción rápida.Más allá de las restricciones de solo SELECT, el validador también bloquea CTE/WITH, subconsultas, declaraciones UNION/INTERSECT/EXCEPT y funciones con valores de tabla (generar_series, pg_dormir…), funciones de ventana, cotización en dólares y cláusulas de bloqueo (PARA ACTUALIZAR). Un exhaustivo recorrido de seguridad recorre todo el árbol de sintaxis abstracta, incluidas DISTINCT ON, OFFSET, FETCH y cláusulas agregadas, para garantizar que ninguna función prohibida se escape a través de un nodo AST no inspeccionado.
Agentes de IA en Postgres: llamadas a funciones, no SQL sin restricciones
Los agentes creados con marcos como LangChain o LlamaIndex pueden llamar a los puntos finales REST de Aurabase (NL2SQL, RAG, consultas de bases de datos) como herramientas nativas invocadas desde su propio bucle de llamada de funciones. NL2SQL desempeña un papel preciso: transformar la subconsulta del agente en SQL validado y seguro, en lugar de otorgarle al agente una ejecución SQL sin restricciones.
En la práctica, la herramienta expuesta al agente envuelve una llamada HTTP estándar al punto final NL2SQL: el SDK ejecuta la solicitud sin requerir complementos de marco personalizados:
Preguntas frecuentes
DA EL SIGUIENTE PASO
Conecte NL2SQL y RAG nativo directamente a su base de datos Postgres.
Cero tuberías de terceros, integradas directamente en el motor backend.
No se requiere tarjeta de crédito · 500 MB gratis · 50,000 MAU