LangChain vs LlamaIndex pour des agents Postgres : lequel choisir

LlamaIndex modélise d'abord des données : documents, nœuds, index, moteur de requête. Un VectorStoreIndex ou un SQLDatabase sont des citoyens de première classe, pas des outils ajoutés à un agent générique. Les deux sont open source (licence MIT), disponibles en Python et en TypeScript, et couvrent aujourd'hui un périmètre qui se recoupe largement : agents, RAG, appel d'outils, connexion SQL.

Cette convergence rend la comparaison plus utile sur l'architecture que sur la liste de fonctionnalités : les deux savent, presque, faire la même chose. Ce qui change, c'est comment.

from langchain_community.utilities import SQLDatabase
from langchain_community.agent_toolkits import create_sql_agent
from langchain_openai import ChatOpenAI
# Chaîne obtenue depuis Studio → Paramètres → Connexion.
# search_path route vers le schéma du projet (voir doc SQLAlchemy/psycopg pour
# l’encodage exact du paramètre "options" selon le pilote utilisé).
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 ?"})

Côté LlamaIndex, l'abstraction équivalente est llama_index.core.SQLDatabase, elle aussi construite sur un moteur SQLAlchemy. Le moteur de requête NLSQLTableQueryEngine traduit une question en langage naturel vers une requête SQL, l'exécute, puis reformule le résultat en réponse.

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 ?")

Aucun des deux extraits ne dépend d'Aurabase. Un pilote SQLAlchemy et une chaîne de connexion Postgres standard suffisent, exactement comme pour Supabase, RDS, ou une instance auto-hébergée.

LlamaIndex répond avec ses Workflows : une orchestration pilotée par événements, où chaque étape émet et consomme des événements typés. Un moteur de requête SQL ou vectoriel s'y branche directement comme une étape, sans couche d'adaptation supplémentaire, puisque ces moteurs sont déjà des primitives natives du framework.

Pour un agent qui interroge Postgres, la différence pratique est celle-ci : LangGraph donne un contrôle fin sur les branchements et les nouvelles tentatives autour d'un appel SQL. LlamaIndex demande moins de code de liaison quand la question porte d'abord sur des données déjà indexées par le framework.

LangChain couvre le même besoin via ses retrievers et ses chaînes de récupération, avec une intégration tout aussi mature dans l'écosystème LangGraph. La différence tient moins à la capacité qu'à l'endroit où vit la logique métier : intégrée à l'index côté LlamaIndex, assemblée explicitement dans une chaîne côté LangChain.

Les deux savent utiliser pgvector comme base vectorielle : llama-index-vector-stores-postgres côté LlamaIndex, la classe PGVector du paquet langchain-postgres côté LangChain. Sur un projet Aurabase, pgvector 0.8.6 est déjà présent dans l'image Postgres tenant : les deux paquets s'y connectent avec la même chaîne de connexion, sans étape d'activation séparée.

AutoGen, projet de recherche Microsoft, prend une approche différente : des agents qui dialoguent entre eux (AssistantAgent, UserProxyAgent, GroupChat), avec la possibilité d'exécuter du code dans un environnement isolé. La coordination ressemble à une conversation, pas à un graphe d'état explicite comme LangGraph.

Aucun des deux ne remplace la couche de connexion aux données. Un agent CrewAI ou AutoGen qui doit lire Postgres appelle, en pratique, un outil SQL construit avec LangChain ou LlamaIndex, ou une simple fonction Python autour de psycopg2. CrewAI et AutoGen répondent à « qui fait quoi et dans quel ordre », pas à « comment lire la base ».

C'est une différence structurelle avec le NL2SQL natif d'Aurabase, qui traduit une question en SQL côté serveur, valide la requête générée (parsing SQL, rejet des champs serveur usurpés) et borne le LIMIT avant exécution. Ce n'est pas la même brique : un endpoint NL2SQL répond en un tour, avec des garde-fous posés par la plateforme ; un agent LangChain ou LlamaIndex raisonne en plusieurs étapes, avec des garde-fous à assembler soi-même.

En pratique, les deux approches se complètent plutôt qu'elles ne s'excluent : un endpoint NL2SQL borné pour une question simple exposée à un utilisateur final, un agent pour un raisonnement multi-étapes qui combine plusieurs outils au-delà de SQL.

# 1. Récupérer la chaîne de connexion Postgres du projet
#    (Studio → Paramètres → Connexion, ou n’importe quel Postgres managé)
export AURA_DB_URL="postgresql+psycopg2://aura:***@<host>:5432/aura_db_master?options=-csearch_path%3Dproject_<id>"
# 2. Installer le pilote SQL et le framework choisi
pip install langchain langchain-community langchain-openai psycopg2-binary
# ou, côté LlamaIndex :
pip install llama-index llama-index-llms-openai psycopg2-binary
# 3. Créer un rôle Postgres dédié, lecture seule si l’agent ne doit qu’interroger
CREATE ROLE agent_readonly LOGIN PASSWORD '***';
GRANT SELECT ON ALL TABLES IN SCHEMA project_<id> TO agent_readonly;

La troisième étape compte plus que le choix du framework. Un rôle Postgres restreint aux droits réellement nécessaires reste le seul garde-fou fiable contre une requête générée qui dépasse son périmètre, quel que soit l'agent qui l'exécute. Voir la documentation IA pour la configuration des fournisseurs LLM natifs d'Aurabase (OpenAI, Anthropic, Gemini) utilisables côté agent.

• LangChain : si l'agent doit combiner plusieurs outils hétérogènes (SQL, API externes, recherche web) avec un contrôle fin du flux via LangGraph, et si l'équipe valorise l'écosystème d'intégrations le plus large du marché.
• LlamaIndex : si le cœur du projet est le RAG ou l'interrogation de données déjà indexées, avec un besoin fort de connecteurs de sources et un modèle d'index/requête qui colle directement au cas d'usage.
• CrewAI ou AutoGen en complément : dès qu'un seul agent ne suffit plus et qu'il faut répartir un travail entre plusieurs rôles spécialisés, au-dessus de l'un ou l'autre des deux frameworks de données.

Les deux peuvent aussi cohabiter dans un même projet : un moteur de requête LlamaIndex exposé comme outil dans un agent LangGraph est un pattern courant. Maintenir deux frameworks a un coût de complexité réel, à mettre en balance avec le gain avant de l'adopter par défaut.