LangChain frente a LlamaIndex para agentes Postgres

LangChain y LlamaIndex aparecieron durante el mismo período, tras el lanzamiento de ChatGPT a finales de 2022. Su punto de partida difiere notablemente. LangChain modela una aplicación LLM como una cadena de pasos componibles: mensaje, llamada de modelo, herramienta, memoria, todo ensamblado mediante LCEL o un gráfico LangGraph.

LlamaIndex primero modela datos: documentos, nodos, índices, motor de consultas. Un VectorStoreIndex o SQLDatabase son ciudadanos de primera clase, no herramientas agregadas a un agente genérico. Ambos son de código abierto (licencia MIT), disponibles en Python y TypeScript, y hoy cubren un ámbito en gran medida superpuesto: agentes, RAG, llamada a herramientas, conexión SQL.

Esta convergencia hace que la comparación sea más útil en la arquitectura que en la lista de características: ambas pueden, casi, hacer lo mismo. Lo que cambia es cómo.

En el lado de LangChain, el módulo langchain_community.utilities.SQLDatabase encapsula un motor SQLAlchemy. Luego, el agente create_sql_agent lo expone como un conjunto de herramientas: enumerar tablas, describir un esquema, ejecutar una consulta, verificar una consulta antes de su ejecución.

from langchain_community.utilities import SQLDatabase
from langchain_community.agent_toolkits import create_sql_agent
from langchain_openai import ChatOpenAI

# Canal obtenido de Estudio → Configuración → Conexión.
# ruta search_path al esquema del proyecto (consulte el documento SQLAlchemy/psycopg para
# la codificación exacta del parámetro "opciones" dependiendo del controlador utilizado).
db = SQLDatabase.from_uri(
    "postgresql+psycopg2://aura:***@<host>:5432/aura_db_master?options=-csearch_path%3Dproject_<id>"
)

llm = ChatOpenAI(model="gpt-4o-mini")
agent = create_sql_agent(llm=llm, db=db, agent_type="tool-calling")

agent.invoke({"input": "Combien de commandes la semaine dernière ?"})

En el lado de LlamaIndex, la abstracción equivalente es llama_index.core.SQLDatabase, también construida en un motor SQLAlchemy. El motor de consultas NLSQLTableQueryEngine traduce una pregunta en lenguaje natural a una consulta SQL, la ejecuta y luego reformula el resultado como respuesta.

from sqlalchemy import create_engine
from llama_index.core import SQLDatabase
from llama_index.core.query_engine import NLSQLTableQueryEngine
from llama_index.llms.openai import OpenAI

engine = create_engine(
    "postgresql+psycopg2://aura:***@<host>:5432/aura_db_master?options=-csearch_path%3Dproject_<id>"
)
sql_database = SQLDatabase(engine, include_tables=["orders", "customers"])

query_engine = NLSQLTableQueryEngine(
    sql_database=sql_database, llm=OpenAI(model="gpt-4o-mini"),
)
response = query_engine.query("Combien de commandes la semaine dernière ?")

Ninguno de los extractos depende de Aurabase. Un controlador SQLAlchemy y una cadena de conexión estándar de Postgres son suficientes, al igual que para Supabase, RDS o una instancia autohospedada.

LangChain propuso por primera vez un bucle de agente clásico (AgentExecutor, patrón ReAct). Desde entonces, el proyecto ha hecho converger a sus agentes hacia LangGraph: un agente se representa allí como un gráfico explícito de nodos y bordes, con puntos de control y posible intervención humana entre dos etapas.

LlamaIndex responde con su Workflows: una orquestación basada en eventos, donde cada paso emite y consume eventos escritos. Un motor de consultas SQL o vectorial se conecta directamente como un paso, sin una capa de adaptación adicional, ya que estos motores ya son primitivos nativos del marco.

Para un agente que consulta Postgres, la diferencia práctica es la siguiente: LangGraph brinda un control detallado sobre las ramas y los reintentos en torno a una llamada SQL. LlamaIndex requiere menos código de enlace cuando la primera pregunta se refiere a datos ya indexados por el marco.

Profundice: tutorial de llamada a funciones para un agente de Postgres

LlamaIndex fue diseñado desde el principio para conectar un LLM a fuentes de datos, con un catálogo de conectores (LlamaHub) e índices especializados según el tipo de contenido. RAG sigue siendo el caso de uso más directo del marco, no una característica agregada después del hecho.

LangChain cubre la misma necesidad a través de su retrievers y cadenas de recuperación, con una integración igualmente madura en el ecosistema LangGraph. La diferencia no es tanto sobre la capacidad como sobre dónde reside la lógica empresarial: integrada en el índice en el lado de LlamaIndex, ensamblada explícitamente en una cadena en el lado de LangChain.

Ambos saben cómo usar pgvector como base vectorial: llama-index-vector-stores-postgres en el lado LlamaIndex, la clase PGVector del paquete langchain-postgres en el lado LangChain. En un proyecto de Aurabase, pgvector 0.8.6 ya está presente en la imagen del inquilino de Postgres: ambos paquetes se conectan con la misma cadena de conexión, sin un paso de activación por separado.

Profundizar: construcción de una canalización RAG de Postgres/pgvector

CrewAI organiza varios agentes por rol: cada agente recibe un objetivo, un contexto (backstory) y herramientas, agrupados en Crew con Task ejecutados en secuencia o según una jerarquía. Es un marco de orquestación completo, no una extensión de LangChain.

AutoGen, un proyecto de investigación de Microsoft, adopta un enfoque diferente: agentes que se comunican entre sí (AssistantAgent, UserProxyAgent, GroupChat), con la capacidad de ejecutar código en un entorno aislado. La coordinación parece una conversación, no un gráfico de estado explícito como LangGraph.

Ninguno reemplaza la capa de conexión de datos. Un agente CrewAI o AutoGen que necesita leer llamadas de Postgres, en la práctica, una herramienta SQL creada con LangChain o LlamaIndex, o una función simple de Python alrededor de psycopg2. CrewAI y AutoGen responden "quién hace qué y en qué orden", no "cómo leer la base de datos".

create_sql_agent y NLSQLTableQueryEngine ejecutan la consulta generada por el modelo en la conexión proporcionada. No limita el número de filas devueltas de forma predeterminada ni bloquea una solicitud de escritura: la barrera de seguridad real es la función de Postgres utilizada en la cadena de conexión, no una opción del marco.

Esta es una diferencia estructural con el NL2SQL nativo de Aurabase, que traduce una pregunta a SQL en el lado del servidor, valida la consulta generada (análisis de SQL, rechazo de campos de servidor falsificados) y limita el LIMIT antes de la ejecución. No es el mismo ladrillo: un punto final NL2SQL responde en un solo turno, con barandillas instaladas por la plataforma; un agente de LangChain o LlamaIndex razona en varias etapas, con salvaguardias para montar usted mismo.

En la práctica, los dos enfoques se complementan entre sí en lugar de excluirse: un punto final NL2SQL limitado para una pregunta sencilla expuesta a un usuario final, un agente para el razonamiento de varios pasos que combina varias herramientas más allá de SQL.

Ver también: Tutorial de NL2SQL sobre Postgres con Aurabase

Tres pasos son suficientes, independientemente del marco elegido, y no dependen de ningún conector específico de plataforma.

# 1. Recupere la cadena de conexión de Postgres del proyecto.
#    (Estudio → Configuración → Conexión, o cualquier Postgres administrado)
export AURA_DB_URL="postgresql+psycopg2://aura:***@<host>:5432/aura_db_master?options=-csearch_path%3Dproject_<id>"

# 2. Instale el controlador SQL y el marco elegido.
pip install langchain langchain-community langchain-openai psycopg2-binary
# o, del lado de LlamaIndex:
pip install llama-index llama-index-llms-openai psycopg2-binary

# 3. Cree una función de Postgres dedicada, de solo lectura si el agente solo debe sondear
CREATE ROLE agent_readonly LOGIN PASSWORD '***';
GRANT SELECT ON ALL TABLES IN SCHEMA project_<id> TO agent_readonly;

El tercer paso importa más que la elección del marco. Una función de Postgres restringida a derechos verdaderamente necesarios sigue siendo la única protección confiable contra una solicitud generada que excede su alcance, independientemente del agente que la ejecute. Consulte la documentación de AI para conocer la configuración de los proveedores LLM nativos de Aurabase (OpenAI, Anthropic, Gemini) utilizables en el lado del agente.

Ninguno de los marcos es estrictamente superior para un agente conectado a Postgres. El contexto de partida del proyecto es más decisivo que la lista de funcionalidades.

• LangChain: si el agente debe combinar varias herramientas heterogéneas (SQL, API externas, búsqueda web) con un control preciso del flujo a través de LangGraph, y si el equipo valora el ecosistema de integración más amplio del mercado.
• LlamaIndex: si el corazón del proyecto es el RAG o la consulta de datos ya indexados, con una gran necesidad de conectores de origen y un modelo de indexación/consulta que se ajuste directamente al caso de uso.
• CrewAI o AutoGen además: tan pronto como un solo agente ya no es suficiente y el trabajo debe distribuirse entre varios roles especializados, por encima de uno u otro de los dos marcos de datos.

Los dos también pueden coexistir en el mismo proyecto: un motor de consulta LlamaIndex expuesto como herramienta en un agente LangGraph es un patrón común. Mantener dos marcos tiene un costo de complejidad real, que debe sopesarse con la ganancia antes de adoptarlo de forma predeterminada.