AI Gateway Postgres : fournisseurs natifs vs endpoints compatibles OpenAI

Sur un backend Postgres comme Aurabase, ce choix a une conséquence directe : le même gateway alimente le chat applicatif, le NL2SQL (traduction langage naturel vers SQL) et le RAG (recherche vectorielle pgvector). Un fournisseur mal intégré dégrade les trois fonctionnalités à la fois, pas une seule. C’est ce qui rend la distinction natif/compatible plus qu’un détail d’implémentation.

Un endpoint compatible OpenAI, lui, réutilise le client OpenAI existant et change seulement l’URL de base. Cela fonctionne parce que le fournisseur tiers (Mistral, Scaleway AI, Ollama) a choisi d’imiter le contrat d’API d’OpenAI, souvent avec des écarts : pas de champ de tokens de raisonnement séparé, pas de garantie sur la forme exacte des erreurs. La compatibilité s’arrête là où l’imitation s’arrête.

pub mod anthropic;
pub mod gemini;
pub mod openai;

Chaque module implémente le trait ChatProvider (complétion, streaming, nom de modèle). Deux d’entre eux, OpenAI et Gemini, implémentent en plus EmbeddingProvider. Anthropic n’en a pas besoin : Claude n’expose pas d’API d’embeddings côté fournisseur, un fait produit d’Anthropic lui-même, pas une lacune du code Aurabase.

# Provider par défaut : OpenAI natif
OPENAI_API_KEY=sk-...
# Basculer sur un fournisseur compatible OpenAI (Mistral, Scaleway AI, Ollama...)
OPENAI_API_KEY=<clé du fournisseur choisi>
OPENAI_BASE_URL=<URL de base compatible OpenAI du fournisseur>
# ex. Mistral : https://api.mistral.ai/v1

Le comportement change en conséquence. Les erreurs HTTP restent classifiées par le même mécanisme (429 → limite de débit, 5xx → transitoire et retryable, 404 → modèle inconnu), parce que la classification vit au niveau du transport HTTP, pas du parsing spécifique au fournisseur. Ce qui ne suit pas : le comptage précis des tokens de raisonnement, propre au client dédié Gemini.

Chaque fournisseur nomme aussi différemment le motif d’arrêt d’une réponse : length chez OpenAI, MAX_TOKENS chez Gemini, max_tokens chez Anthropic, pour la même réalité (troncature). Le code normalise ces trois vocabulaires vers un jeu commun (stop, length, content_filter, tool_use, other). Sans cette normalisation, un client multi-fournisseur devrait connaître les trois vocabulaires pour détecter une réponse tronquée.

La facturation illustre le même risque. Chez OpenAI et Anthropic, le raisonnement du modèle est déjà compris dans le compteur de tokens de sortie facturés. Chez Gemini, thoughtsTokenCount s’ajoute séparément à candidatesTokenCount : l’ignorer sous-estime le coût réel d’une requête. Un adaptateur générique compatible OpenAI n’a aucune raison de connaître cette particularité, propre au format de réponse natif de Gemini.

Ces acteurs répondent à un besoin réel : réduire le couplage entre le code applicatif et un fournisseur LLM donné. La différence avec Aurabase tient à l’intégration. Le gateway ne vit pas à côté du backend : il partage le même service que le NL2SQL et le RAG, sur la même base Postgres. Le compromis inverse existe aussi : un proxy dédié comme LiteLLM couvre en général davantage de fournisseurs qu’un gateway intégré à un backend applicatif.

Le compromis inverse existe. Si votre priorité est de couvrir un très grand nombre de fournisseurs, ou si le gateway doit servir plusieurs backends indépendants et pas seulement un projet Postgres, un proxy généraliste comme LiteLLM reste souvent le bon choix. Aurabase ne cherche pas à concurrencer cette largeur de couverture : le pari est la profondeur sur 3 fournisseurs majeurs, intégrée au reste du backend.

Pour comprendre comment cette intégration change concrètement l’usage du NL2SQL par rapport à une approche par connecteurs externes, l’approche choisie par Supabase, voir Supabase mise sur des connecteurs, pas sur du NL2SQL natif.

Pour voir ce gateway à l’œuvre sur un cas concret, voir le tutoriel NL2SQL sur Postgres. Pour le détail des capacités IA natives d’Aurabase, voir la page IA native.