Comment exécuter une jointure entre PostgreSQL et MongoDB

La question revient dès qu'une application stocke ses commandes dans PostgreSQL et ses logs ou événements dans MongoDB. À un moment, il faut croiser ces données : enrichir une liste d'utilisateurs SQL avec leurs interactions stockées en NoSQL, ou regrouper les commandes d'un compte avec ses sessions applicatives. Or, ni PostgreSQL ni MongoDB ne savent joindre l'autre directement.

Il existe quatre approches pratiques en 2026. Chacune a son contexte d'usage, son coût d'installation et ses limites de volume. Le choix dépend moins de la technique que de la fréquence d'exécution et du volume traité.

Pourquoi cette jointure n'est pas native

Les deux moteurs ne partagent ni protocole, ni modèle de données, ni planificateur de requêtes. PostgreSQL parle SQL et raisonne en tables relationnelles. MongoDB parle son propre protocole binaire et raisonne en documents BSON. Aucun mécanisme commun ne permet à un moteur d'interroger l'autre sans intermédiaire.

Cela laisse trois familles de solutions : déplacer les données vers un emplacement commun, faire faire à un moteur un appel vers l'autre via un connecteur, ou exécuter le JOIN dans un troisième moteur qui sait lire les deux sources. Les quatre approches qui suivent se rangent dans une de ces familles.

Synchroniser une copie avec un ETL

Le plus direct en apparence consiste à répliquer les données MongoDB vers PostgreSQL, ou l'inverse, puis à faire la jointure dans le moteur cible. Un script lit les documents BSON, les aplatit en colonnes, et fait des INSERT côté PostgreSQL. Une fois les données présentes des deux côtés, le JOIN devient un SQL classique.

L'intérêt est réel : le résultat tourne dans un moteur connu, les performances sont prévisibles, et les requêtes peuvent être optimisées avec des index. Le coût est dans le pipeline. Il faut écrire la synchronisation, gérer les schémas qui dérivent côté MongoDB, traiter les conflits de typage, et accepter une latence puisque les données ne sont jamais à jour à la seconde.

Outils typiques : Airbyte, Meltano, ou un script Python avec pymongo et psycopg. Pour une analytique froide récurrente, c'est viable. Pour une exploration ponctuelle, c'est disproportionné.

Les Foreign Data Wrappers PostgreSQL

PostgreSQL propose depuis longtemps les FDW, un mécanisme qui permet d'exposer une source externe comme une table virtuelle. Le projet mongo_fdw déclare une collection MongoDB comme foreign table dans PostgreSQL, puis on la requête en SQL standard, y compris dans un JOIN avec des tables locales.

La séquence d'installation passe par CREATE EXTENSION mongo_fdw, puis CREATE SERVER, CREATE USER MAPPING et CREATE FOREIGN TABLE. Une fois la table déclarée, un SELECT classique avec un JOIN suffit, et PostgreSQL délègue la lecture MongoDB en interne.

L'approche garde une seule interface SQL et évite la copie de données. La performance dépend du pushdown : si le planificateur PostgreSQL ne pousse pas les filtres jusqu'à MongoDB, le serveur télécharge la collection entière avant de filtrer côté PostgreSQL. Sur de gros volumes, cela devient inutilisable. Le mapping des types BSON vers SQL demande aussi de la rigueur, et tous les opérateurs MongoDB ne sont pas exposés. À privilégier quand un usage PostgreSQL central existe déjà et que les volumes MongoDB sont raisonnables.

Les moteurs de fédération distribués : Trino, Presto, Starburst

Trino, anciennement PrestoSQL, est un moteur SQL distribué conçu pour exécuter des requêtes sur plusieurs sources hétérogènes. Il dispose d'un connecteur PostgreSQL et d'un connecteur MongoDB. On déclare deux catalogues, et on écrit un SELECT qui mentionne par exemple postgresql.public.orders et mongodb.logs.events dans le même JOIN.

Trino résout le problème proprement : un planificateur unique, du pushdown réel quand le connecteur le supporte, une exécution distribuée pour les gros volumes. C'est l'outil de référence côté data engineering.

Le coût est ailleurs : Trino est une infrastructure à part entière. Cluster à déployer, configuration des catalogues, gestion des credentials, monitoring, montée de version. Pour un développeur qui veut explorer une jointure ad hoc depuis son poste, c'est l'équivalent d'installer un data warehouse pour répondre à une question. À privilégier quand la fédération est un besoin récurrent à l'échelle d'une équipe data.

La fédération côté client : QoreDB et DuckDB

QoreDB prend une autre voie : exécuter la fédération localement, au moment de la requête, sans serveur ni cluster à provisionner. Le mécanisme repose sur DuckDB, un moteur SQL analytique embarqué dans le binaire de QoreDB.

Le déroulé concret : on déclare ses deux connexions (PostgreSQL et MongoDB) dans QoreDB, on ouvre un onglet SQL et on écrit une requête qui mentionne les deux sources via une syntaxe à trois parties, du type pg_prod.public.users JOIN mongo_logs.app.events. QoreDB détecte les références fédérées, lit les données nécessaires dans chaque source, les charge dans une instance DuckDB en mémoire, exécute le JOIN, puis renvoie le résultat. L'instance DuckDB est éphémère : créée pour la requête, détruite après.

Plusieurs choix techniques rendent l'approche viable pour un usage poste de travail. La lecture des sources se fait en parallèle, avec un timeout par source (30 secondes par défaut) et un timeout global pour l'ensemble du pipeline. Une limite de lignes par source est appliquée pour éviter qu'une collection volumineuse ne sature la RAM. Aucun état persistant n'est créé : pas de copie permanente, pas de cache à invalider, pas de schéma à maintenir.

L'angle est assumé : ce n'est pas une infrastructure de fédération de production, c'est un outil d'exploration et de croisement ponctuel sur un poste de développeur. Pour croiser quelques centaines de milliers ou quelques millions de lignes afin de comprendre un bug, produire un rapport ou valider une intuition, c'est suffisant et immédiat. Pour des volumes plus larges ou un usage répété par une équipe entière, Trino reste le bon outil.

Quelle approche selon le contexte

Pour un pipeline analytique récurrent à grande échelle, sur des volumes importants : ETL planifié ou Trino, selon la fraîcheur attendue et la complexité du SQL.

Pour exposer durablement des collections MongoDB dans un applicatif PostgreSQL existant : mongo_fdw, en validant le pushdown sur les requêtes critiques avec EXPLAIN.

Pour une exploration ponctuelle ou un croisement à la demande depuis un poste de travail : fédération côté client comme QoreDB, qui évite tout setup serveur et garde la requête entièrement locale.

Le besoin de joindre PostgreSQL et MongoDB n'est pas un cas exotique, c'est une réalité de la plupart des stacks modernes où l'OLTP relationnel cohabite avec un stockage documentaire. Choisir l'approche dépend du contexte : qui exécute la requête, à quelle fréquence, sur quel volume. Les quatre options existent et sont matures, à condition de prendre celle qui correspond au besoin réel plutôt que celle qui paraît la plus impressionnante.