LangChain rispetto a LlamaIndex per gli agenti Postgres

LangChain e LlamaIndex sono apparsi nello stesso periodo, sulla scia del rilascio di ChatGPT alla fine del 2022. Il loro punto di partenza è notevolmente diverso. LangChain modella un'applicazione LLM come una catena di passaggi componibili: prompt, chiamata del modello, strumento, memoria, il tutto assemblato tramite LCEL o un grafico LangGraph.

LlamaIndex modella innanzitutto i dati: documenti, nodi, indici, motore di query. A VectorStoreIndex o SQLDatabase sono cittadini di prima classe, non strumenti aggiunti a un agente generico. Entrambi sono open source (licenza MIT), disponibili in Python e TypeScript, e oggi coprono un ambito in gran parte sovrapposto: agenti, RAG, chiamata strumento, connessione SQL.

Questa convergenza rende il confronto più utile sull'architettura che sull'elenco delle caratteristiche: entrambe possono, quasi, fare la stessa cosa. Ciò che cambia è il come.

Sul lato LangChain, il modulo langchain_community.utilities.SQLDatabase incapsula un motore SQLAlchemy. L'agente create_sql_agent lo espone quindi come un insieme di strumenti: elenca tabelle, descrive uno schema, esegue una query, controlla una query prima dell'esecuzione.

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

# Canale ottenuto da Studio → Impostazioni → Connessione.
# search_path instrada allo schema del progetto (vedi il documento SQLAlchemy/psycopg per
# l'esatta codifica del parametro "opzioni" a seconda del driver utilizzato).
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 ?"})

Sul lato LlamaIndex, l'astrazione equivalente è llama_index.core.SQLDatabase, anch'essa costruita su un motore SQLAlchemy. Il motore di query NLSQLTableQueryEngine traduce una domanda in linguaggio naturale in una query SQL, la esegue e quindi riformula il risultato come risposta.

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

Nessuno dei due estratti dipende da Aurabase. Sono sufficienti un driver SQLAlchemy e una stringa di connessione Postgres standard, proprio come per Supabase, RDS o un'istanza self-hosted.

LangChain ha proposto per primo un classico loop di agenti (AgentExecutor, pattern ReAct). Da allora il progetto ha fatto convergere i suoi agenti verso LangGraph: un agente è rappresentato lì come un grafico esplicito di nodi e bordi, con checkpoint e possibile intervento umano tra due fasi.

LlamaIndex risponde con il suo Workflows: un'orchestrazione basata sugli eventi, in cui ogni passaggio emette e consuma eventi tipizzati. Un motore di query SQL o vettoriale si inserisce direttamente come passo, senza un ulteriore livello di adattamento, poiché questi motori sono già primitivi nativi del framework.

Per un agente che interroga Postgres, la differenza pratica è questa: LangGraph fornisce un controllo capillare sui rami e sui tentativi attorno a una chiamata SQL. LlamaIndex richiede meno codice di collegamento quando la domanda riguarda per la prima volta i dati già indicizzati dal framework.

Approfondisci: tutorial sulle chiamate di funzioni per un agente Postgres

LlamaIndex è stato progettato fin dall'inizio per connettere un LLM alle fonti dati, con un catalogo di connettori (LlamaHub) e indici specializzati a seconda della tipologia di contenuto. RAG rimane il caso d'uso più diretto del framework, non una funzionalità aggiunta a posteriori.

LangChain copre la stessa esigenza tramite retrievers e catene di recupero, con un'integrazione altrettanto matura nell'ecosistema LangGraph. La differenza non riguarda tanto la capacità quanto il luogo in cui vive la logica aziendale: integrata nell'indice sul lato LlamaIndex, assemblata esplicitamente in una catena sul lato LangChain.

Entrambi sanno come usare pgvector come base vettoriale: llama-index-vector-stores-postgres sul lato LlamaIndex, la classe PGVector del pacchetto langchain-postgres sul lato LangChain. Su un progetto Aurabase, pgvector 0.8.6 è già presente nell'immagine tenant Postgres: entrambi i pacchetti si connettono ad esso con la stessa stringa di connessione, senza un passaggio di attivazione separato.

Scavare più a fondo: costruire una pipeline RAG Postgres/pgvector

CrewAI orchestra diversi agenti per ruolo: ogni agente riceve un obiettivo, un contesto (backstory) e strumenti, raggruppati in Crew con Task eseguiti in sequenza o secondo una gerarchia. È un framework di orchestrazione a tutti gli effetti, non un'estensione di LangChain.

AutoGen, un progetto di ricerca Microsoft, adotta un approccio diverso: agenti che parlano tra loro (AssistantAgent, UserProxyAgent, GroupChat), con la capacità di eseguire codice in un ambiente isolato. Il coordinamento assomiglia a una conversazione, non a un grafico di stato esplicito come LangGraph.

Nessuno dei due sostituisce il livello di connessione dati. Un agente CrewAI o AutoGen che deve leggere Postgres chiama, in pratica, uno strumento SQL costruito con LangChain o LlamaIndex, o una semplice funzione Python attorno a psycopg2. CrewAI e AutoGen rispondono "chi fa cosa e in quale ordine", non "come leggere il database".

create_sql_agent e NLSQLTableQueryEngine eseguono la query generata dal modello rispetto alla connessione fornita. Non limita il numero di righe restituite per impostazione predefinita, né blocca una richiesta di scrittura: il guardrail effettivo è il ruolo Postgres utilizzato nella stringa di connessione, non un'opzione del framework.

Questa è una differenza strutturale con NL2SQL nativo di Aurabase, che traduce una domanda in SQL sul lato server, convalida la query generata (analisi SQL, rifiuto dei campi del server falsificati) e delimita LIMIT prima dell'esecuzione. Non è lo stesso mattone: un endpoint NL2SQL risponde in un turno, con i guardrail installati dalla piattaforma; un agente LangChain o LlamaIndex ragiona in più fasi, con garanzie da assemblare tu stesso.

In pratica, i due approcci si completano a vicenda anziché escludersi a vicenda: un endpoint NL2SQL limitato per una semplice domanda esposta a un utente finale, un agente per il ragionamento in più fasi che combina diversi strumenti oltre SQL.

Vedi anche: tutorial NL2SQL su Postgres con Aurabase

Sono sufficienti tre passaggi, indipendentemente dal framework scelto, e non dipendono da alcun connettore specifico della piattaforma.

# 1. Recupera la stringa di connessione Postgres del progetto
#    (Studio → Impostazioni → Connessione o qualsiasi Postgres gestito)
export AURA_DB_URL="postgresql+psycopg2://aura:***@<host>:5432/aura_db_master?options=-csearch_path%3Dproject_<id>"

# 2. Installare il driver SQL e il framework scelto
pip install langchain langchain-community langchain-openai psycopg2-binary
# oppure, lato LlamaIndex:
pip install llama-index llama-index-llms-openai psycopg2-binary

# 3. Creare un ruolo Postgres dedicato, di sola lettura se l'agente deve solo eseguire il polling
CREATE ROLE agent_readonly LOGIN PASSWORD '***';
GRANT SELECT ON ALL TABLES IN SCHEMA project_<id> TO agent_readonly;

Il terzo passaggio conta più della scelta del contesto. Un ruolo Postgres limitato ai diritti veramente necessari rimane l'unica protezione affidabile contro una richiesta generata che supera il suo ambito, indipendentemente dall'agente che la esegue. Consulta la documentazione AI per la configurazione dei provider LLM nativi di Aurabase (OpenAI, Anthropic, Gemini) utilizzabili lato agente.

Nessuno dei due framework è strettamente superiore per un agente connesso a Postgres. Il contesto di partenza del progetto è più decisivo dell’elenco delle funzionalità.

• LangChain: se l'agente deve combinare diversi strumenti eterogenei (SQL, API esterne, ricerca web) con un controllo accurato del flusso tramite LangGraph e se il team apprezza l'ecosistema di integrazione più ampio sul mercato.
• LlamaIndex: se il cuore del progetto è il RAG o l'interrogazione di dati già indicizzati, con una forte necessità di connettori di origine e di un modello di indice/query che si adatti direttamente al caso d'uso.
• CrewAI o AutoGen in aggiunta: non appena un solo agente non è più sufficiente e il lavoro deve essere distribuito tra più ruoli specializzati, sopra l'uno o l'altro dei due framework di dati.

I due possono anche coesistere nello stesso progetto: un motore di query LlamaIndex esposto come strumento in un agente LangGraph è un modello comune. Mantenere due framework ha un costo di complessità reale, da valutare rispetto al guadagno prima di adottarlo per impostazione predefinita.