Abbiamo verificato questa distinzione direttamente nel codice del servizio aura-ai, non in una pagina di marketing: tre moduli del provider (anthropic, gemini, openai) compongono il gateway, niente di più. Il resto del panorama conferma che si tratta di una vera categoria di sviluppatori, non di un argomento di marketing isolato. Neon pubblica due pagine dedicate (“AI Gateway” e “Backend per agenti AI”), LiteLLM si è affermato come progetto open source di riferimento e Braintrust gli dedica i propri confronti.
L'essenziale
- 3 fornitori nativi verificati nel codice: OpenAI, Anthropic (Claude), Google Gemini (
aura-ai/src/llm/mod.rs). - Mistral, Scaleway AI e Ollama passano attraverso l'adattatore OpenAI generico (
OPENAI_BASE_URL), non attraverso un client dedicato. - Il nativo porta più della semplice connessione: interruttore automatico per (progetto, fornitore), nuovo tentativo di backoff, catena di fallback (ordine predefinito Anthropic → OpenAI → Google), standardizzazione dei motivi di spegnimento.
- Anthropic copre solo la chat: nessuna API incorporata, a differenza di OpenAI e Gemini che le coprono entrambe.
- Neon, LiteLLM e Braintrust confermano la stessa categoria lato mercato, con tre approcci diversi: gateway gestito, proxy open source, contenuto comparativo.
Cos'è un gateway AI su un backend Postgres?
Un AI Gateway centralizza le chiamate ai fornitori LLM esterni dietro un'unica interfaccia, invece di codificare ciascuna integrazione SDK sul lato dell'applicazione. Le chiavi API rimangono lato server, mai esposte al client. Il gateway aggiunge un livello comune di tentativi, failover e conteggio dei costi oltre ai provider con formati di risposta diversi.
Su un backend Postgres come Aurabase, questa scelta ha una conseguenza diretta: lo stesso gateway alimenta la chat dell'applicazione, NL2SQL (traduzione del linguaggio naturale in SQL) e RAG (ricerca vettoriale pgvettoriale). Un fornitore scarsamente integrato degrada tutte e tre le funzionalità contemporaneamente, non solo una. Questo è ciò che rende la distinzione nativo/compatibile più di un dettaglio implementativo.
Provider nativo o endpoint compatibile: la differenza concreta
Un client nativo codifica la forma reale dell'API del provider: struttura della richiesta, formato della risposta, campi di utilizzo specifici di questo provider. È il caso di Anthropic, la cui API “Messages” non assomiglia a quella di OpenAI, o di Gemini, il cui conteggio dei token di ragionamento (thoughtsTokenCount) viene aggiunto al contatore di output invece di essere già incluso lì.
Un endpoint compatibile con OpenAI riutilizza il client OpenAI esistente e modifica solo l'URL di base. Funziona perché il fornitore di terze parti (Mistral, Scaleway AI, Ollama) ha scelto di imitare il contratto API di OpenAI, spesso con deviazioni: nessun campo token di ragionamento separato, nessuna garanzia sull'esatta forma degli errori. La compatibilità finisce dove finisce l’imitazione.
3 clienti LLM nativi presso Aurabase, non di più
Il file che organizza i provider in aura-ai non lascia spazio ad ambiguità. Tre moduli, uno per provider nativo, nient'altro dichiarato.
Ogni modulo implementa il tratto ChatProvider (completamento, streaming, nome del modello). Due di loro, OpenAI e Gemini, implementano inoltre EmbeddingProvider. Anthropic non ne ha bisogno: Claude non espone un'API di incorporamento lato fornitore, un fatto del prodotto stesso di Anthropic, non un difetto del codice Aurabase.
| OpenAI | CLIENTE NATIVO | Chat + calcolo degli incorporamenti vettoriali ad alta fedeltà |
|---|---|---|
| Antropico (Claude) | CLIENTE NATIVO | Inferenza chat e completamento del modello strutturato Claude |
| Google Gemelli | CLIENTE NATIVO | Chat + incorporamenti, conteggio dei token di ragionamento additivo |
| Maestrale | POSIZIONE COMPATIBILE | Routing tramite protocollo compatibile OpenAI standard (URL personalizzato) |
| IA della scala | POSIZIONE COMPATIBILE | Instradamento tramite client openai.rs, variabile OPENAI_BASE_URL |
| Ollama (ospitato autonomamente) | POSIZIONE COMPATIBILE | Instradamento tramite client openai.rs, variabile OPENAI_BASE_URL |
Collega Mistral, Scaleway AI o Ollama a un progetto Aurabase
La configurazione di Mistral, Scaleway AI o Ollama non richiede un nuovo modulo: la stessa variabile OPENAI_BASE_URL reindirizza il client openai.rs su un altro endpoint compatibile. Si tratta di un'attivazione/disattivazione della configurazione, non di uno sviluppo.
Il comportamento cambia di conseguenza. Gli errori HTTP rimangono classificati con lo stesso meccanismo (429 → limite di velocità, 5xx → transitorio e riprovabile, 404 → modello sconosciuto), perché la classificazione risiede a livello di trasporto HTTP, non di analisi specifica del provider. Cosa non segue: il conteggio preciso dei gettoni ragionamento, specifico per il client Gemini dedicato.
Perché il nativo è un punto di svolta: passaggio, errori, fatturazione
Il gateway Aurabase aggiunge tre meccanismi di resilienza oltre ai tre client nativi. Un interruttore automatico per coppia (progetto, provider) interrompe le chiamate a un provider ripetutamente fallito, con un token sonda in uno stato semi-aperto prima di riaprirlo. Un nuovo tentativo di backoff esponenziale con jitter riavvia errori temporanei (timeout, 5xx, 429), senza dipendenza da una libreria di numeri casuali esterna.
Quando sono configurati più provider in una catena, viene effettuato un solo tentativo per provider prima di passare al successivo, per evitare un'amplificazione (riprova × fallback) che moltiplicherebbe le chiamate upstream e la latenza totale. L'ordine predefinito di questo canale è Anthropic, quindi OpenAI, quindi Google Gemini.
Ciascun fornitore nomina inoltre il motivo dell'interruzione di una risposta in modo diverso: length su OpenAI, MAX_TOKENS su Gemini, max_tokens su Anthropic, per la stessa realtà (troncamento). Il codice normalizza questi tre vocabolari verso un insieme comune (stop, length, content_filter, tool_use, other). Senza questa standardizzazione, un cliente multivendor avrebbe bisogno di conoscere tutti e tre i vocabolari per rilevare una risposta troncata.
La fatturazione illustra lo stesso rischio. In OpenAI e Anthropic la logica del modello è già inclusa nel contatore dei token di output addebitati. In Gemini, thoughtsTokenCount viene aggiunto separatamente a candidatesTokenCount: ignorandolo si sottostima il costo reale di una query. Un adattatore generico compatibile con OpenAI non ha motivo di conoscere questa particolarità, specifica del formato di risposta nativo di Gemini.
Neon, LiteLLM, Braintrust: dove sono i migliori gateway LLM nel 2026?
Il mercato conferma che un gateway AI è diventato un elemento atteso e non un argomento di marketing isolato. Neon pubblica due pagine di prodotto dedicate, "AI Gateway" e "Backend per agenti AI", entrambe orientate agli sviluppatori Postgres. LiteLLM si è affermato come progetto open source di riferimento per unificare le chiamate a un gran numero di fornitori dietro un formato vicino a OpenAI. Braintrust, dal canto suo, pubblica i propri confronti sull'argomento, segno che la categoria è sufficientemente forte da giustificare contenuti editoriali dedicati.
Questi attori rispondono a un'esigenza reale: ridurre l'accoppiamento tra il codice dell'applicazione e un determinato fornitore LLM. La differenza con Aurabase è l'integrazione. Il gateway non vive accanto al backend: condivide lo stesso servizio di NL2SQL e RAG, sullo stesso database Postgres. Esiste anche il compromesso opposto: un proxy dedicato come LiteLLM copre generalmente più fornitori di un gateway integrato nel backend di un'applicazione.
| Aurabase | Integrato con il backend Postgres (servizio aura-ai) | 3 nativi verificati + compatibilità OpenAI per il resto |
|---|---|---|
| Gateway IA neon | Prodotto dedicato, affiancato al database gestito Postgres | Documentato su due pagine ufficiali separate |
| LiteLLM | Proxy open source indipendente, davanti a qualsiasi backend | Ampia gamma di fornitori tramite un formato vicino a OpenAI |
Quando scegliere un gateway nativo, quando scegliere un proxy generale
Un gateway nativo come quello di Aurabase ha un vantaggio reale quando il backend e l’AI devono rimanere nello stesso sistema: NL2SQL, RAG e chat applicativa condividono quindi la stessa policy di resilienza e la stessa fatturazione, senza servizi aggiuntivi da operare.
Esiste il compromesso opposto. Se la tua priorità è coprire un numero molto elevato di provider, o se il gateway deve servire diversi backend indipendenti e non solo un progetto Postgres, un proxy generale come LiteLLM rimane spesso la scelta giusta. Aurabase non cerca di competere con questa ampiezza di copertura: la scommessa è la profondità tra 3 principali fornitori, integrati con il resto del backend.
Per capire come questa integrazione cambi concretamente l'utilizzo di NL2SQL rispetto ad un approccio che utilizza connettori esterni, l'approccio scelto da Supabase, vedere Supabase si basa sui connettori, non su NL2SQL nativo.
Gateway nativo integrato rispetto al proxy LLM generale
Sintesi dei criteri che realmente distinguono i due approcci, senza giudizi di valore: ciascuno risponde a un bisogno diverso.
| Fornitori | Approfondimento sui 3 principali fornitori + compatibilità OpenAI per il resto | Ampia gamma di fornitori, integrazione generalmente uniforme |
|---|---|---|
| Chiavi API | Crittografato sul lato backend, stesso servizio del database | Crittografato sul lato proxy, servizio separato dal backend dell'applicazione |
| Collegamento NL2SQL/RAG | Stesso servizio, stesso provider risolutore | Nessun collegamento nativo, crea la tua integrazione |
| Resilienza | Interruttore automatico di (progetto, fornitore), fallback, nuovo tentativo di backoff | Dipende dalla configurazione scelta per il proxy |
| Distribuzione | Un servizio in meno da gestire (già nel backend) | Staccabile, riutilizzabile su più progetti/backend |
Per vedere questo gateway all'opera in un caso concreto, vedere il tutorial NL2SQL su Postgres. Per i dettagli sulle funzionalità AI native di Aurabase, consultare la pagina AI nativa.