Voir les catégories

Comment exposer une base de données PostgreSQL en tant qu'API REST sécurisée

11 min de lecture

Logo PostgreSQL POSTGRESQL API REST

Transformer une requête PostgreSQL en une requête sécurisée API REST — pas de PostgREST, pas de serveur à héberger.

Enregistrez une requête SQL sur votre base de données Postgres, générez une clé API par destinataire et fournissez à un partenaire un point de terminaison JSON opérationnel. Aucun accès ouvert 5432 port, pas d'identifiants partagés, pas de service Express à compiler ni à corriger — juste un port géré en lecture seule API REST Postgres en quelques minutes.

Aucun port entrant Clés par destinataire Lecture seule appliquée Rien à déployer

Query Streams est une plateforme d'intégration de bases de données sécurisée et en temps réel qui transforme toute requête PostgreSQL enregistrée en un point de terminaison d'API REST prêt pour les partenaires, avec des clés par destinataire, une application en lecture seule et une piste d'audit complète. Vous obtenez une vie API REST Postgres sans ouvrir de port de base de données, partager d'identifiants ou héberger une passerelle. Pour en savoir plus, rendez-vous sur QueryStreams.com. et Inscrivez-vous gratuitement pour publier votre premier point de terminaison PostgreSQL en quelques minutes.

Pourquoi exposer une base de données PostgreSQL sous forme d'API REST ?

Tôt ou tard, une personne extérieure à votre équipe aura besoin de données stockées dans PostgreSQL : un client souhaite consulter ses chiffres sur un tableau de bord, un fournisseur préfère un flux en temps réel à un fichier CSV quotidien, ou l’application d’un partenaire doit accéder à une partie de vos tables. Les solutions habituelles présentent toutes des risques : vous envoyez par e-mail des exportations obsolètes dès leur réception, vous distribuez un accès en lecture seule. psql Une connexion qui perdure au-delà de la durée de la mission, ou bien vous mettez en place un petit service et vous héritez indéfiniment de son authentification, de son TLS et de ses correctifs. API REST PostgreSQL Voici la version simplifiée : le partenaire reçoit une URL et un jeton, et non votre base de données. La difficulté a toujours résidé dans la création et l’exploitation sécurisée de cette API. Query Streams la transforme en une requête enregistrée associée à une clé.

Aucun port Postgres ouvert

Vous ne vous exposez jamais 5432 Pour accéder à Internet, il faut ouvrir une brèche dans votre pare-feu. L'agent réseau établit des appels sortants ; les appels entrants empruntent cette unique connexion sortante.

Clés API par destinataire

Chaque bénéficiaire reçoit le sien qsapi_* clé. Révoquez-en une sans toucher aux autres et sans changer votre mot de passe PostgreSQL.

Conçu pour la lecture seule

Un validateur en lecture seule rejette toute instruction autre que SELECT avant qu'elle n'atteigne Postgres. Il n'y a pas d'erreur. MISE À JOUR ou BAISSE chemin à travers l'API.

Vos données SQL restent confidentielles

Le destinataire voit l'URL du point de terminaison, la réponse JSON et les filtres que vous avez exposés — jamais votre requête SQL, votre schéma, votre nom d'hôte ou votre chaîne de connexion.

Rien à héberger ni à patcher

Pas de conteneur PostgREST, pas d'application Express, pas de proxy inverse. Le point de terminaison fonctionne comme une fonctionnalité gérée ; il n'y a donc pas de pipeline de déploiement ni de rotation TLS à gérer.

Permanent, éphémère ou autodestructeur

Rendez un point de terminaison permanent, programmez son expiration à une date précise ou attribuez-lui un budget d'appels fixe qui s'autodétruit après un nombre défini de requêtes.

Les méthodes habituelles pour implémenter une API REST sur Postgres — et pourquoi elles sont néfastes

Il existe des outils performants pour cela. Le hic ? Chacun d’eux vous laisse responsable de l’infrastructure, d’une exposition réseau, ou des deux. Voici comment les approches courantes se comparent à un point de terminaison partagé Query Streams lorsque l’objectif est simplement de permettre à un partenaire spécifique de lire un ensemble de résultats spécifique.

Préoccupation PostgREST / Hasura (auto-hébergé) DIY Express / FastAPI Flux de requêtes
Base de données accessible depuis l'API Doit atteindre Postgres (souvent un nouveau chemin réseau / port public) Doit atteindre Postgres Agent sortant uniquement — aucun port entrant
Ce que le destinataire détient Une URL dans votre schéma Une URL vers votre service Une clé à usage unique pour une seule requête
Exposition du schéma Schéma complet exposé par défaut Quel que soit le code que vous programmez manuellement Une seule requête enregistrée, rien d'autre.
Clés par destinataire + révocation Construisez-le vous-même Construisez-le vous-même Intégré dans
Journal d'audit de chaque appel Ajoutez-le vous-même Ajoutez-le vous-même Intégré dans
Vous gérez / corrigez / faites tourner le TLS Oui, pour toujours Oui, pour toujours Géré pour vous
Temps jusqu'au premier point final Quelques heures à quelques jours Jours Minutes

Vous recherchez une alternative à PostgREST pour le partage de partenaires ?

PostgREST est idéal si vous souhaitez une interface REST complète et auto-hébergée, basée sur votre propre schéma. En revanche, si vous préférez fournir à un partenaire désigné un ensemble de résultats contrôlé et en lecture seule (avec sa propre clé, un journal d'audit et sans serveur à exécuter), Query Streams répond précisément à ce besoin. Les deux solutions peuvent coexister : PostgREST pour votre application interne et Query Streams pour le partage externe.

Comment Query Streams transforme une requête Postgres en une API REST

Une fois l'agent réseau installé et votre connecteur PostgreSQL configuré, la promotion d'une requête enregistrée vers un point de terminaison REST partagé se fait en trois étapes environ. Si vous utilisez déjà Query Streams pour Excel, Google Sheets ou le serveur MCP, votre agent et votre connecteur sont déjà en place ; vous passez directement à l'étape deux.

1

Connectez-vous à PostgreSQL via l'agent

Installez l'agent réseau à côté de votre base de données et ajoutez un connecteur PostgreSQL avec un rôle standard en lecture seule. L'agent établit une connexion TLS sortante avec Query Streams ; votre base de données n'est jamais exposée à Internet.

2

Enregistrer une requête SQL

Écrivez le SELECTIONNER Dans le générateur de requêtes de votre connexion Postgres, les jointures, les CTE, les fonctions de fenêtrage et les paramètres sont les bienvenus. Nommez votre requête et enregistrez-la. Tout élément pouvant être sélectionné peut devenir un point de terminaison.

3

Faites-en la promotion et partagez une clé

Ouvrez l'onglet Installation, choisissez le type de point de terminaison (permanent, temporaire ou à budget d'appels) et le format de sortie, puis invitez un destinataire par e-mail. Il recevra un lien magique et son propre qsapi_* clé.

Une requête enregistrée, de nombreuses surfaces

La même requête PostgreSQL enregistrée peut déclencher une actualisation Excel, l'affichage d'une barre latérale Google Sheets, ou une conversation Claude ou Cursor. Serveur PostgreSQL MCP, et un point de terminaison REST destiné aux partenaires. Vous créez la requête une seule fois ; Query Streams gère les interfaces.

Aucun port Postgres ouvert, aucune information d'identification partagée

Le modèle de sécurité est la raison pour laquelle les équipes privilégient cette solution plutôt qu'un port de base de données public. Votre mot de passe PostgreSQL est stocké exclusivement dans le coffre-fort d'identifiants chiffré de l'Agent sur votre réseau ; il n'est jamais transmis à notre cloud et reste invisible pour le destinataire. De plus, chaque point de terminaison vous offre des contrôles spécifiques à chaque destinataire, que vous pouvez renforcer avant tout partage.

Agent sortant uniquement

L'agent se connecte à agent.querystreams.com sur le port 443. Votre pare-feu voit un trafic HTTPS sortant normal — aucun port entrant, aucun VPN, aucun tunnel.

Application en lecture seule

Un validateur s'exécute dans l'agent, sur votre réseau, avant que toute requête n'atteigne Postgres. Les requêtes autres que SELECT sont rejetées. VIOLATION EN LECTURE SEULE.

Listes blanches IP + CORS

Associer la clé d'un destinataire à des adresses IP ou des plages CIDR spécifiques et restreindre les origines de navigateur autorisées à appeler chaque point de terminaison. Les appels hors liste sont bloqués avant toute exécution de requête SQL.

Limites de débit + quotas d'octets

Des limites de débit à deux niveaux (par clé et par point de terminaison) plus une limite mensuelle optionnelle en octets permettent de maintenir un destinataire bruyant ou incontrôlable dans un rayon d'explosion sûr.

Appelez votre API REST PostgreSQL

Les destinataires appellent le point de terminaison comme n'importe quelle autre API REST : un jeton d'authentification et une URL. Tout paramètre de requête enregistré que vous avez exposé peut être défini pour chaque appel, dans la chaîne de requête. OBTENIR ou dans un corps JSON pour POSTEL'agent lie ces valeurs en tant que paramètres d'instruction préparée appropriés, jamais par concaténation de chaînes, de sorte qu'un destinataire ne peut pas contourner un filtre pour injecter du SQL.

GET avec paramètre de filtre
# Appel du destinataire vers votre point de terminaison basé sur Postgres boucle -H « Autorisation : Porteur qsapi_K7…ZmQ » \ «https://api.querystreams.com/v1/endpoints/orders-by-region?region=EMEA&since=2026-01-01»

Choisissez le format de sortie pour chaque appel avec le Accepter en-tête (ou un ?format= paramètre de requête) : JSON pour un seul tableau, CSV pour les tableurs et pandas, ou, sur un point de terminaison de flux, NDJSON (une ligne JSON par ligne) pour les pipelines d'analyse à la demande. Pour les consommateurs sensibles à la bande passante, optez pour LZ4 Compression de la charge utile avec Accept-Encoding: lz4; les réponses non compressées reçoivent également une compression standard gzip sur le réseau automatiquement. Pour une description complète des modes statique et de flux, des quatre combinaisons de fils et de la génération OpenAPI 3.1, consultez le API REST instantanée pour les bases de données SQL guide.

Modalités de facturation de la consommation

La plateforme API est incluse dans chaque forfait et utilise le même quota mensuel de données qu'Excel, Google Sheets et le serveur MCP — les appels LZ4 sont facturés en octets compressés, sinon en octets non compressés. Comment le quota de données partagées est-il calculé ?

Connectez-le à Power BI, Tableau et à tout logiciel capable de lire du JSON.

Parce que chaque point de terminaison renvoie une norme JSON — avec CSV et NDJSON en streaming à disposition — tout outil capable de lire un flux REST consomme directement vos données PostgreSQL, sans rien avoir à installer de son côté. Power Query est le pont le plus facile vers la suite Microsoft BI : dans Power BI choisir Récupérer des données → Depuis le Web, collez l'URL du point de terminaison, ajoutez votre Autorisation L'en-tête est analysé par Power Query, qui convertit le JSON en un tableau actualisable alimentant votre modèle de données. (Pour les données en direct dans une feuille de calcul, la méthode native est utilisée.) Module complémentaire Excel Query Streams c'est la voie la plus simple — Power Query est là lorsque vous souhaitez intégrer les données directement dans le modèle Power BI.)

Logo Microsoft Power Query Power Query Récupérer les données → Depuis le Web, collez l'URL et le jeton d'authentification, puis développez le JSON en un tableau actualisable.
Logo Microsoft Power BI Power BI Même moteur Power Query — chargez le point de terminaison directement dans votre modèle et planifiez une actualisation
Logo Tableau Tableau Configurez un connecteur de données Web ou une source JSON pour qu'elle pointe vers le point de terminaison des tableaux de bord en direct.
Logo du facteur Facteur Importez la spécification OpenAPI 3.1, puis envoyez, inspectez et partagez des requêtes en un seul clic.

Il nourrit également n8n, Qlik, boucle, Python (demandes ou pandas.read_json), Insomnia, Hoppscotch — ou tout script ou flux de travail capable d'envoyer une requête HTTP et de lire du JSON.

Fonctionne également avec Postgres géré

Peu importe où votre instance PostgreSQL est exécutée. L'agent se connecte de la même manière à un serveur local ou à un service géré : Amazon RDS pour PostgreSQL et Aurora PostgreSQL, Azure Database pour PostgreSQL, Google Cloud SQL pour PostgreSQL, Supabase ou Neon. Pour une latence minimale, déployez l'agent sur le même réseau ou dans la même région que la base de données. Un compte Query Streams peut exécuter plusieurs agents dans différentes régions et clouds, et un point de terminaison unique se comporte de manière identique quel que soit l'agent qui le gère.

Plus que PostgreSQL

Le même flux de travail permet de transférer une requête enregistrée depuis Microsoft SQL Server, MySQL, MariaDB, SQLite, Microsoft Access, Snowflake, Oracle, BigQuery ou DuckDB vers un point de terminaison REST. PostgreSQL est simplement l'un des points de départ les plus populaires. Consultez la documentation. Guides d'installation des connecteurs pour la liste actuelle.

Questions fréquemment posées

Dois-je ouvrir un port ou exposer PostgreSQL sur Internet ? +
Non — l'agent réseau établit une connexion sortante via TLS sur le port 443, donc les appels entrants empruntent cette unique connexion sortante et votre port PostgreSQL (5432 (par défaut) n'est jamais exposé. Comment fonctionne une connexion sortante uniquement ?
Le destinataire peut-il voir mes identifiants SQL ou mes identifiants de base de données ? +
Jamais — le destinataire ne voit que l'URL du point de terminaison, la réponse et les filtres que vous avez exposés, tandis que vos mots de passe SQL et PostgreSQL restent dans le magasin d'informations d'identification chiffré de l'agent sur votre réseau. Ce qui reste privé derrière chaque clé →
En quoi est-ce différent de PostgREST ou Hasura ? +
PostgREST et Hasura génèrent une API étendue pour votre schéma et fonctionnent comme des services que vous hébergez, sécurisez et rendez accessibles depuis Postgres. Query Streams adopte une approche différente, plus ciblée, pour le partage sortant : vous exposez une requête enregistrée comme point de terminaison, chaque destinataire reçoit sa propre clé révocable, chaque appel est audité et vous n’avez rien à déployer ni à corriger. De nombreuses équipes utilisent les deux : un outil interne comme PostgREST et Query Streams pour le partage de données en externe.
Quels formats de sortie l'API peut-elle renvoyer ? +
JSON (par défaut), CSV et — sur un point de terminaison de flux continu — NDJSON, choisi pour chaque appel avec le Accepter en-tête ou un ?format= paramètre, avec compression de charge utile LZ4 optionnelle. Formats de transmission et options de compression →
Les destinataires peuvent-ils filtrer les résultats ou reçoivent-ils une requête fixe ? +
C'est vous qui décidez. Tout paramètre que vous exposez dans la requête enregistrée devient un filtre que le destinataire peut définir pour chaque appel, sur la chaîne de requête. OBTENIR ou un corps JSON pour POSTELes paramètres que vous ne spécifiez pas restent inchangés. L'agent associe chaque valeur à un paramètre d'instruction préparée ; par conséquent, les filtres ne peuvent pas être utilisés pour injecter du code SQL.
Un point de terminaison peut-il expirer ou s'autodétruire ? +
Oui, un point de terminaison peut être permanent, expirer à une date précise ou avoir un budget d'appels fixe, et vous pouvez révoquer instantanément la clé de n'importe quel destinataire sans toucher aux autres ni modifier le mot de passe de votre base de données. Durée de vie des points de terminaison et révocation des clés par destinataire →
Est-ce compatible avec Amazon RDS, Azure, Cloud SQL, Supabase ou Neon ? +
Oui. L'agent se connecte à n'importe quelle instance PostgreSQL accessible, qu'elle soit sur site ou gérée : Amazon RDS et Aurora PostgreSQL, Azure Database pour PostgreSQL, Google Cloud SQL pour PostgreSQL, Supabase et Neon sont compatibles. Pour une latence optimale, exécutez l'agent dans la même région que la base de données ; un seul compte peut exécuter plusieurs agents sur différents clouds et régions.
Le destinataire a-t-il besoin d'un compte Query Streams ? +
Le partage par e-mail est recommandé — le destinataire reçoit un lien magique et une organisation gratuite créée automatiquement — ou vous pouvez émettre une clé de service pour un accès machine à machine sans surveillance. Réclamations par bénéficiaire versus clés de service →

Commencer

Publiez gratuitement votre première API REST PostgreSQL.

Inscrivez-vous, installez l'agent réseau à côté de votre base de données Postgres, enregistrez une requête SQL et envoyez par e-mail à un destinataire un lien magique. Les clés par destinataire, l'accès en lecture seule et un journal d'audit complet sont activés dès le premier appel.

Guides associés : API REST instantanée pour les bases de données SQL | Plateforme API REST de base de données | Connectez PostgreSQL à Claude via MCP | Guides d'installation des connecteurs

Catégorie : Plateforme API

Mots-clés : API REST PostgreSQL, PostgreSQL, API REST, exposer PostgreSQL en tant qu'API, alternative à PostgreSQL, partage de données PostgreSQL, clés par destinataire, API sans code, API REST de base de données

Méta-description : Transformez une requête PostgreSQL en une API REST sécurisée en lecture seule avec des clés par destinataire — sans port ouvert, sans PostgREST, sans code.

Updated on 16 juin 2026

Powered by BetterDocs