Connecter PostgreSQL

Datarelix se connecte à PostgreSQL via un service de requêtes en lecture seule. Toutes les requêtes sont validées et exécutées à l’intérieur de ce service — le modèle ne voit jamais les identifiants de connexion et n’exécute jamais de SQL brut sur votre base de données.

Prérequis

Un serveur PostgreSQL (toute version encore activement prise en charge — 13+).
Un rôle de base de données disposant de CONNECT sur la base et de USAGE + SELECT sur les schémas et tables que vous voulez analyser. Faites-en un rôle LOGIN qui n’est pas superutilisateur et ne dispose d’aucun privilège d’écriture.
Une accessibilité réseau depuis les IP de sortie de Datarelix vers votre serveur Postgres.

Modes d’authentification

Username & password

Authentification SQL standard par nom d’utilisateur et mot de passe de base de données. Le mot de passe est stocké chiffré ; tous les autres champs de connexion sont stockés en configuration simple.

Configuration — créer un rôle en lecture seule

Exécutez ce qui suit dans votre base de données (en tant que superutilisateur ou rôle disposant de CREATEROLE) :

CREATE USER datarelix_reader WITH PASSWORD 'choose-a-strong-password';
GRANT CONNECT ON DATABASE your_db TO datarelix_reader;
GRANT USAGE ON SCHEMA public TO datarelix_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO datarelix_reader;
ALTER DEFAULT PRIVILEGES FOR ROLE table_owner IN SCHEMA public
  GRANT SELECT ON TABLES TO datarelix_reader;

Remplacez your_db et public par vos véritables noms de base et de schéma. Voir la référence GRANT de PostgreSQL pour le modèle de privilèges complet.

table_owner doit être le rôle qui crée les futures tables. Les droits par défaut concernent ce créateur, pas tous les rôles du schéma. L’administrateur doit pouvoir créer le compte et accorder les droits sur les objets. Examinez les rôles hérités et les droits PUBLIC, notamment les fonctions et tables temporaires : ces commandes ne décrivent pas tous les droits effectifs. Droits par défaut, modèle de privilèges.

Où trouver vos identifiants

Champ	Où le trouver
Host	Votre console cloud — AWS RDS : point de terminaison de l’instance ; GCP Cloud SQL : IP publique ou privée ; Azure Database for PostgreSQL : nom d’hôte du serveur (`*.postgres.database.azure.com`)
Port	`5432` par défaut ; visible dans le panneau d’informations de connexion de votre console cloud
Database	Le nom de la base — à lister avec `\l` dans psql
Username	Le rôle que vous venez de créer
Password	Le mot de passe défini dans `CREATE USER`

Ce qu’il faut saisir

Host:            your-host.example.com
Port:            5432
Database:        your_db
Username:        datarelix_reader
Password:        ••••••••
SSL mode:        require
Allowed schema:  public

Connection string

Collez une URL postgresql:// — la chaîne de connexion — au lieu de remplir chaque champ. Pratique quand votre fournisseur cloud vous en livre une toute faite.

Où trouver votre chaîne de connexion

AWS RDS — console RDS → votre instance de base → Connectivity & security → copiez le nom d’hôte du point de terminaison, puis composez : postgresql://datarelix_reader:password@endpoint:5432/dbname?sslmode=require
GCP Cloud SQL — Cloud SQL → votre instance → Overview → copiez l’IP publique ; un Cloud SQL Auth Proxy local n’est pas automatiquement joignable depuis Datarelix
Azure Database for PostgreSQL — portail Azure → votre serveur → Connect → copiez les informations de connexion et remplacez le mot de passe par le vôtre
Supabase — Project settings → Database → Connection string → onglet URI
Neon — Dashboard → votre projet → Connection Details → copiez la chaîne de connexion

Ce qu’il faut saisir

postgresql://datarelix_reader:your-password@your-host.example.com:5432/your_db?sslmode=require

Poolers de connexions (mode transaction ou mode session)

Commencez par une connexion directe ou un pool en mode session. La compatibilité du mode transaction dépend du client, du fournisseur et de la configuration. PgBouncer peut gérer les requêtes préparées au niveau protocole avec max_prepared_statements activé ; SQL PREPARE et l’état de session ont d’autres restrictions. Confirmez la compatibilité avant de choisir ce mode. Matrice PgBouncer

Pour Supabase, vérifiez le point de connexion, le réseau et le nom d’utilisateur dans son guide.

Modes SSL

Le champ SSL mode (mode SSL) correspond aux modes SSL standard de libpq :

Mode	Signification
`disable`	Pas de TLS. À proscrire sur des réseaux publics.
`allow` / `prefer`	`allow` essaie d’abord le clair ; `prefer` essaie TLS. Les deux permettent un repli.
`require`	TLS obligatoire ; le certificat serveur n’est pas vérifié. Valeur par défaut. Protège de l’écoute passive, mais pas d’une attaque active de type MITM.
`verify-ca`	TLS + vérification que le certificat serveur remonte à une autorité de confiance.
`verify-full`	TLS + vérification du certificat et de la correspondance du nom d’hôte. Le plus strict. Recommandé pour un Postgres managé en production.

Sémantique de la portée

Le champ Allowed schema (schéma autorisé) sélectionne les schémas disponibles pour la découverte et les requêtes. Valeur par défaut : public.

Sélectionnez les schémas approuvés dans le périmètre de connexion et vérifiez les droits sur chacun.

Découverte

Entièrement prise en charge. La découverte lit information_schema et pg_catalog pour lister les tables, colonnes, types, nullabilité, valeurs par défaut, clés primaires et clés étrangères ; le rôle ne voit que les objets sur lesquels il a des droits. L’analyse IA du schéma, facultative, ajoute des descriptions et propose les relations non déclarées à partir des conventions de nommage.

Limites

Aucune requête d’écriture ni DDL — Datarelix rejette toute instruction qui n’est pas une lecture avant son exécution.
Seuls les schémas autorisés sont disponibles pour la découverte et les requêtes.
Les résultats sont plafonnés à 5 000 lignes — les requêtes sans LIMIT en reçoivent un automatiquement.

Dépannage

Symptôme	Cause probable	Solution
`Connection refused`	Pare-feu ou port incorrect	Vérifiez que `psql -h host -p 5432 -U user db` fonctionne depuis le même réseau.
`password authentication failed`	Mauvais identifiants ou méthode `pg_hba.conf` inadaptée	Testez d’abord avec `psql` ; vérifiez la méthode d’authentification attendue pour le rôle. Sur Azure, utilisez le nom d’utilisateur simple — Flexible Server n’a pas besoin du suffixe `user@servername` (il ne concernait que Single Server, retiré du service). Sur les poolers Supabase, le nom d’utilisateur est `postgres.<project-ref>`.
`prepared statement ... already exists` / `does not exist`	Connexion via un pooler en mode transaction	Utilisez un pooler en mode session ou une connexion directe (Supabase : port `5432`, pas `6543`).
`SSL connection required`	Le serveur impose TLS, le mode est `disable`/`prefer`	Passez le mode SSL à `require` ou plus strict.
`relation does not exist`	Mauvais schéma	Réglez Allowed schema sur le schéma propriétaire de la table ; `\dn` dans psql liste les schémas.
`permission denied for table X`	Le rôle n’a pas `SELECT` sur la table	`GRANT SELECT ON ALL TABLES IN SCHEMA X TO role`, plus `ALTER DEFAULT PRIVILEGES IN SCHEMA X GRANT SELECT ON TABLES TO role` pour les tables à venir.