Une instruction SQL à travers toutes vos bases de données.
Vos commandes sont dans MySQL. Vos clients sont dans PostgreSQL. Les cibles dont tout le monde parle se trouvent sur un serveur SQL Server au siège social. requête fédérée vous permet d'écrire un texte ordinaire SELECTIONNER qui lit les trois simultanément et vous fournit un seul tableau — aucune exportation, rien de copié nulle part et rien de nouveau à ouvrir sur votre pare-feu.
On every plan, including Free · Free runs 2 sources and 250 result rows — the ceilings grow with your tier
38 Connecteurs de bases de données — effectuez des jointures entre n'importe lesquelles, dans n'importe quelle combinaison.
À leurs côtés dans les flux de requêtes : 8 Connecteurs d'API, interrogés avec la même requête SQL
53 au total. Vos connecteurs API sont interrogés avec SQL comme tout le reste — et une requête fédérée joint vos sources. base de données relations. Consultez le connecteur API
Placez le nom de la connexion devant la table.
C'est la seule nouveauté sur cette page. Chaque nom mis en évidence ci-dessous correspond à une base de données différente, située à un emplacement différent, et accessible par un agent réseau différent ; il s'agit pourtant d'une seule et même requête.
-- une seule requête fédérée · rien de copié nulle part
SELECTIONNER région c,
PAYS(*) AS ordres,
SOMME(o.total) AS revenus, cible
DE mysql_prod.shop.orders1 o
JOINDRE pg_crm.public.clients2 c ON c.id = o.customer_id
JOINDRE mssql_erp.dbo.region_targets3 t ON t.région = c.région
OÙ o.placed_at >= DATE '2026-07-01'
GROUPE PAR c.région, t.cible
ORDER BY recettes DESC;mysql_prod, pg_crm et mssql_erp ce sont simplement les noms que vous avez donnés à vos propres relations — les trois parties sont connexion, schéma, tableC'est ce que les gens entendent par un base de données fédéréeTrois bases de données distinctes répondent à une même question ; aucune n’est fusionnée ni déplacée. Schéma illustratif ; vos tables resteront vos tables.
Où chaque nom se résout
mysql_prod
MySQL · commandes
Agent cloud
Filtre les données jusqu'au mois de juillet, puis calcule le chiffre d'affaires total par client avant tout envoi.
pg_crm
PostgreSQL · clients publics
Agent régional
Renvoie uniquement les colonnes id et region — les deux seules qui correspondent aux noms de la requête.
mssql_erp
SQL Server · dbo.region_targets
agent du siège social
Transmet la cible par région, écrite en T-SQL pour une exécution native.
Trois agents, trois réseaux, une seule déclaration — et aucun d'eux n'a ouvert de port pour y parvenir.
Plus de portée, pas plus d'exposition
La lecture simultanée de deux bases de données emprunte exactement le même chemin que la lecture d'une seule. Aucun nouveau chemin n'est ouvert pour y parvenir.
Sortant uniquement
L'agent établit une connexion chiffrée vers Query Streams et y achemine la requête et les résultats. Aucun port entrant, aucun VPN, aucune modification du pare-feu : vos identifiants restent toujours sur votre réseau.
Lecture seule, chaque pièce
Chaque élément de la requête est vérifié avant d'être transmis : SELECTIONNER, AVEC et EXPLIQUER Uniquement. Une requête fédérée ne peut écrire dans aucune de vos bases de données, et les données rejetées ne les atteignent jamais.
Il ne peut pas s'échapper avec votre serveur
Il existe une limite à la quantité de données qu'une base de données peut transmettre pour une requête unique, et l'agent s'arrête dès que cette limite est atteinte. Une erreur dans une OÙ Cette clause vous coûte un message d'erreur, pas un après-midi.
Trois étapes, et aucune d'entre elles ne constitue un pipeline de données
Choisissez vos connexions
Choisissez au moins deux connexions parmi celles déjà configurées par votre équipe. Deux connexions constituent le minimum pour qu'une requête soit fédérée. Aucune donnée n'est copiée et aucun nouveau mot de passe n'est créé.
Écrivez une déclaration
Nommez chaque table comme suit : table de schéma de connexionEnsuite, écrivez du SQL classique. Avant l'exécution, vous pouvez consulter le plan d'exécution : quelle base de données est interrogée et quelle requête est traitée. Vous pouvez aussi décrire la requête et laisser Nova générer le plan.
Enregistrez-le comme n'importe quelle autre requête
Une fois fonctionnelle, la requête est enregistrée et peut donc être partagée, filtrée, envoyée sous forme de rapport hebdomadaire, publiée en tant que point de terminaison API ou intégrée à une feuille de calcul.
Chaque base de données effectue sa propre part du travail
La méthode la plus simple pour fusionner deux bases de données consiste à transférer les deux tables sur le réseau et à effectuer le tri ensuite. Cette méthode est lente et implique le transfert d'une quantité de données bien supérieure à celle nécessaire pour la requête.
Nous procédons donc à l'inverse. Le filtrage, la sélection des colonnes et le calcul des totaux sont confiés à… retour à chaque base de données pour qu'elle se fasse automatiquement, dans sa propre langue. Un rapport qui regroupe des millions de lignes renvoie le quelques totaux groupés — et non les millions de rangées qui se trouvent derrière eux.
Ce qui reste, on le fait — et on vous montre de quoi il s'agit. Notre travail consiste à effectuer des jointures entre les bases de données, car aucune d'entre elles ne peut accéder aux autres. Le plan détaille les requêtes adressées à chaque base de données et les opérations que nous avons effectuées, ce qui permet d'identifier rapidement une requête coûteuse. avant Vous le gérez.
Elle préférerait refuser plutôt que d'avoir tort en silence.
Voici la vérité gênante concernant la fusion de bases de données distinctes : elles ne concordent pas toujours. Deux bases de données peuvent être soumises à la même question et renvoyer des réponses différentes, que ce soit au niveau de la dernière décimale, de la définition de l’égalité ou de l’interprétation de « dix premières ».
Si vous êtes novice en la matière, voici la version courte : Une base de données n'est pas qu'un simple amas de lignes. Elle a ses propres règles concernant le calcul des sommes d'argent, le tri des mots et la gestion des valeurs vides. Demandez à deux bases de données différentes de trier la même liste de noms de clients et vous obtiendrez deux résultats différents, non pas parce que l'une est défectueuse, mais parce qu'elles ont été conçues avec des règles différentes. Tout outil de fusion de bases de données doit gérer ce problème. La plupart choisissent discrètement une solution et croisent les doigts. Pas nous.
Ce que nous faisons à la place a exactement deux résultats : et le générateur de requêtes vous indique lequel vous avez obtenu : une pilule de plan qui indique prêt ou refusé au fur et à mesure que vous tapez, et un onglet Plan avec le plan complet en cours.
Lorsque le désaccord porte sur comment Une fois le calcul effectué, nous cessons de solliciter votre base de données pour cette étape et la réalisons lors de l'assemblage, où un ensemble de règles uniformes est appliqué. Cela engendre une légère perte de vitesse, sans incidence sur la précision ni sur votre intervention : vous n'avez rien à faire.
- Argent et précision. Les bases de données gèrent différemment l'arrondi des décimales lorsque les totaux deviennent importants. Si l'arrondi des données en interne peut différer de celui d'une addition centralisée, nous récupérons les chiffres et les additionnons nous-mêmes.
- Tri du texte. Si
avient avantBLa manière dont les accents sont comparés est paramétrée pour chaque base de données. Les comparaisons qui en dépendent sont traitées de manière centralisée et ne sont pas appliquées aux bases de données. - Classement et totaux cumulés. Les fonctions de fenêtrage (numéros de lignes, totaux cumulés, « top 3 par région ») sont toujours calculées après l'arrivée des données, car aucune source ne peut voir les autres.
Lorsque la poursuite changerait quelles lignes Le message d'erreur indique la date et l'heure exactes du retour, car il est impossible de les prévoir avec certitude. La requête n'est donc pas exécutée et le message précise l'expression et la base de données exactes, dans votre propre code SQL, afin que vous sachiez quoi modifier.
- Une fonction que la source ne peut pas réaliser. Si votre filtre utilise une fonction que nous ne pouvons pas reproduire fidèlement dans le dialecte de cette base de données, les seules alternatives sont de lui envoyer une requête plus large que celle que vous avez écrite ou d'inventer un équivalent. Ces deux solutions sont inacceptables, nous les refusons donc.
- Limites de lignes à l'intérieur d'une pièce. A
LIMITEouHAUTAppliquée à une source avant la jointure, cette fonction renvoie un nombre arbitraire de lignes, puis les joint — un tableau d'apparence plausible, mais sans signification. Les limites s'appliquent au résultat final. - Un objectif déplacé. Si une connexion a été redirigée vers une base de données différente depuis la planification de la requête, le plan enregistré est obsolète et nous demandons une nouvelle planification plutôt que d'exécuter le plan d'hier sur les données d'aujourd'hui.
Trois refus, et ce que chacun vous révèle
Impossible d'appuyer LOWER(c.email_domain) = ? jusqu'à mssql_erp : fonction non autorisée par pushdown.
Autrement dit: Votre filtre encapsule une colonne dans une fonction dont la source ne peut être considérée comme fiable et qui ne s'applique pas de la même manière que nous le ferions ; nous ne pouvons donc pas garantir qu'il renvoie les mêmes lignes. Ce qu'il faut faire: Comparez plutôt la colonne brute, ou déplacez cette condition en dehors de la source ; le message vous indique quelle source consulter.
LIMITE 100 Cette méthode ne peut pas être appliquée à une seule source avant la jointure : le résultat serait 100 lignes arbitraires, et non les 100 premières de votre réponse.
Autrement dit: L’expression « les 100 premiers » ne prend tout son sens qu’une fois que tout a été rassemblé et trié. Ce qu'il faut faire: Laissez la limite sur l'énoncé dans son ensemble, c'est là qu'il fonctionne comme prévu.
La source 2 pointe désormais vers une connexion ou une base de données différente de celle utilisée lors de la planification de cette requête.
Autrement dit: quelqu'un a changé quoi pg_crm fait référence à. Ce qu'il faut faire: Ouvrez-le dans le générateur de requêtes et replanifiez-le : en un clic, vous pouvez voir le nouveau plan avant de l’exécuter.
La règle sous-jacente à tout cela : si une requête revenait faux, nous refusons. Si seulement il pouvait revenir lentementNous effectuons le test et vous avertissons. Nous ne prenons jamais de risques en fournissant des données erronées pour votre compte.
Vous n'êtes pas non plus laissé seul face à un refus. Nova, intégrée à l'éditeur du générateur de requêtes, maîtrise parfaitement l'ensemble du système : posez une question, et elle vous explique clairement le refus, réécrit la requête pour qu'elle s'exécute et vérifie le nouveau plan d'exécution. Si vous préférez éviter d'écrire le code SQL, décrivez simplement votre question et Nova générera automatiquement la requête fédérée.
Et pour ceux qui préfèrent les détails à la simple confirmation : l’onglet « Plan » du générateur de requêtes répertorie chaque source, la requête envoyée, les conditions appliquées automatiquement et les étapes finalisées de manière centralisée. Aucune étape de la décision n’est dissimulée, même les cas où nous avons opté pour la solution la plus lente, mais la plus sûre.
Une requête fédérée est simplement une requête
Il ne s'agit pas d'un produit distinct avec ses propres règles. Une fois enregistré, il est traité par toutes les autres parties de Query Streams comme n'importe quel autre code que vous avez écrit.
Générateur de requêtes
Rédigez le code dans le même éditeur, en conservant l'arborescence du schéma sous les yeux. L'onglet « Plan » indique les données demandées à chaque base de données ; l'onglet « Analyse » présente un graphique des performances de chacune.
Nova AI
Décrivez la question en anglais et Nova lira vos schémas et générera l'instruction, en précisant la connexion à laquelle chaque table appartient. Il peut ensuite l'exécuter et afficher le résultat sous forme de graphique.
Google Sheets
Sélectionnez la requête enregistrée dans le module complémentaire et les résultats combinés s'affichent dans vos cellules, formatés et actualisables, comme pour n'importe quelle requête portant sur une seule base de données.
Excel
Même principe dans Excel : exécutez-en une ou une feuille entière, avec des en-têtes, des filtres et des mises à jour fixes qui laissent intactes vos colonnes de formules.
API REST de base de données
Publiez le résultat inter-bases de données sous forme de point de terminaison JSON avec une clé, et celui qui le consomme n'aura jamais besoin de savoir qu'il provient de trois systèmes.
MCP pour assistants IA
Claude et d'autres assistants peuvent lister et exécuter vos requêtes fédérées via MCP, de sorte que la question « comment chaque région s'est-elle comportée la semaine dernière ? » trouve une réponse dans le chat.
Rapports et alertes
Programmez l'envoi et les chiffres combinés vous parviendront via Slack, Google Chat, Discord, Telegram ou par e-mail — ou définissez un seuil et vous ne serez informé que lorsqu'une valeur est atteinte.
Automatisation et partage
Synchronisez le résultat dans une feuille de calcul selon un calendrier prédéfini, ou partagez la requête avec un collègue qui ne verra que des filtres et un bouton Exécuter — jamais votre code SQL ni vos connexions.
Les rapports comportaient auparavant deux exportations et une fonction RECHERCHEV
Pratiquement personne n'utilise une seule base de données. Il y a l'ERP, la base de données de la boutique, le CRM et le système utilisé par la dernière acquisition.
Commandes ici, clients là-bas
La boutique enregistre les commandes dans MySQL ; le CRM gère les clients et les régions dans PostgreSQL. Le calcul du chiffre d'affaires par région ne nécessite plus deux exportations et une recherche, mais une seule requête enregistrée que chacun peut réexécuter.
Après une acquisition
Deux entreprises, deux architectures, un seul dossier à finaliser vendredi. Vous aurez une vue d'ensemble dès le premier jour, mais la migration proprement dite prendra les dix-huit mois habituels.
Stock contre vente
Les niveaux de stock sont enregistrés dans le système de gestion de l'entrepôt situé dans un autre pays ; les ventes sont enregistrées dans la base de données du magasin. Un seul relevé permet de les comparer, et ce même relevé peut ensuite être généré chaque lundi sous forme de rapport.
Une base de données par site, un numéro
Le même schéma est déployé par pays, par locataire ou par atelier. Additionnez-les en une seule requête au lieu de maintenir un script qui exécute la requête cinq fois et effectue le total manuellement.
Base de données fédérée, fédération de données, virtualisation des données
Trois appellations pour des concepts qui se recoupent, et le marketing omniprésent a contribué à brouiller les frontières. Voici la signification de chacune et notre contribution respective.
Une base de données fédérée
A base de données fédérée Un système de bases de données fédérées (ou système de bases de données fédérées) permet à plusieurs bases de données distinctes de fonctionner comme une seule, sans pour autant les fusionner. Chacune conserve son propre espace de stockage, son propre moteur et son propre propriétaire ; une couche supérieure traite la requête et détermine quelle base de données répond à quelle partie.
Cette couche correspond à ce que sont les flux de requêtes. Il n'y a pas de nouvelle base de données sous-jacente, et rien n'y est copié.
fédération de données
fédération de données L'approche consiste à laisser les données là où elles ont été écrites et à les interroger uniquement en cas de besoin, plutôt que de tout extraire d'abord dans une copie centrale. L'alternative est un pipeline et un entrepôt de données : tout est transféré pendant la nuit, puis seule la copie est interrogée.
Les deux approches sont légitimes. La fédération l'emporte lorsque la question concerne plusieurs systèmes, lorsque les données doivent rester en place ou lorsqu'un projet d'entrepôt de données coûterait plus cher que la réponse apportée. Un entrepôt de données reste la meilleure option pour l'analyse historique poussée de volumes importants de données.
virtualisation des données
virtualisation des données est la catégorie des grandes entreprises construites sur la fédération — généralement une requête fédérée plus une couche de modélisation, des outils de mise en cache et de gouvernance, vendue comme une plateforme à part entière.
Nous en sommes délibérément la tranche étroite et honnête : requêtes fédérées sur les connexions que vous avez déjà., au sein même de l'outil que votre équipe utilise déjà pour rédiger ses requêtes. Aucun projet de modélisation, aucun serveur à gérer, aucun consultant.
FAQ sur les requêtes fédérées
Qu'est-ce qu'une requête fédérée ?
Une requête fédérée est une instruction SQL qui interroge plusieurs bases de données distinctes et renvoie un résultat unique. Aucune copie n'est effectuée au préalable : votre instruction est divisée en une petite requête par base de données, chacune traitant les données qu'elle peut, puis les fragments sont assemblés pour former le résultat. Dans Query Streams, une instruction devient fédérée dès qu'elle mentionne au moins deux de vos connexions.
Mes bases de données doivent-elles se trouver au même endroit ?
Non. Ils peuvent se trouver dans différents bureaux, sur différents comptes cloud, dans différents pays, ou une combinaison des trois : l’un dans une salle serveur, l’autre sur un réseau cloud privé, et le dernier sur une machine dans un entrepôt. Chaque emplacement exécute un agent réseau, et chaque agent accède aux flux de requêtes en établissant une connexion sortante. Pour votre pare-feu, il s’agit d’une simple connexion sortante ; il n’y a donc rien à ouvrir ni de VPN à configurer.
Vous pouvez également associer plusieurs bases de données sur un même serveur au même agent ; un agent par emplacement est la norme, et non un par base de données.
Ai-je également besoin d'un entrepôt de données ou d'un pipeline ETL ?
Non, pas pour ça. Il n'y a rien à charger ni de planification à surveiller : la requête lit vos bases de données en direct au moment de son exécution, la réponse ne peut donc pas être obsolète comme le serait une copie de la veille. La fédération ne remplace cependant pas l'analyse historique poussée sur de très grands volumes de données ; cela reste le rôle d'un entrepôt de données. Un test simple : si la question porte sur plusieurs systèmes et doit être à jour, fédérez-la.
Quelles bases de données puis-je fusionner ?
Toutes vos connexions à vos bases de données, quelle que soit leur combinaison : SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, Snowflake, BigQuery, SQLite, Access et DuckDB. Chaque base de données est interrogée dans son propre dialecte, de sorte qu’une même requête peut envoyer HAUT à SQL Server et LIMITE à PostgreSQL sans que vous y pensiez.
Les bases de données diffèrent réellement dans leurs capacités de calcul et leurs méthodes de tri et d'arrondi ; par conséquent, il est impossible de répondre exactement à toutes les combinaisons possibles de chaque expression. Dans ce cas, vous recevez un message précisant l'expression, plutôt qu'une valeur numérique approximative.
Est-ce plus lent que d'interroger une seule base de données ?
Cela dépend de la capacité de chaque base de données à effectuer des tâches de manière autonome ; c’est précisément ce que nous optimisons et ce que le plan vous indique. Lorsque le filtrage et le regroupement sont effectués au sein de vos bases de données, très peu de données sont déplacées et l’exécution se déroule comme une requête classique. En revanche, lorsqu’une jointure importante doit être finalisée par nos soins, davantage de données sont déplacées, et le plan vous en informe avant son exécution. Chaque base de données possède également une limite de requêtes, ce qui permet d’éviter les erreurs et de limiter les performances.
Est-il sûr d'exécuter une seule requête sur plusieurs bases de données de production ?
Il utilise le même modèle de sécurité que toutes les autres requêtes que vous exécutez ici. Chaque élément transite par votre propre agent réseau via une connexion sortante chiffrée — aucun port entrant, aucun VPN, aucune modification du pare-feu — et vos identifiants de base de données ne quittent jamais votre réseau. Chaque élément est vérifié en lecture seule (SELECTIONNER, AVEC, EXPLIQUER), une requête fédérée ne peut écrire nulle part, et chaque base de données ne voit qu'une requête touchant les colonnes que vous avez nommées.
En quoi est-ce différent de Trino, Presto ou Denodo ?
L'idée est la même que celle popularisée par Trino et Presto : une seule requête SQL, distribuée à de nombreuses sources. La différence réside dans la configuration et l'apprentissage nécessaires. Trino et Presto utilisent des clusters à déployer, configurer et intégrer à votre réseau ; les plateformes de virtualisation des données ajoutent une couche de modélisation et une licence. Notre solution offre les mêmes fonctionnalités directement dans l'outil que votre équipe utilise déjà, en accédant aux connexions existantes, sans aucun serveur à gérer.
L'autre différence, c'est que nous refusons. Lorsque les bases de données présentent une divergence susceptible de modifier un résultat, nous interrompons le traitement et indiquons l'expression que nous n'avons pas pu gérer, au lieu de renvoyer une valeur plausible.
Que puis-je faire avec ce résultat ?
Tout ce que vous pouvez faire avec une requête enregistrée, car c'est bien de cela qu'il s'agit. Enregistrez-la, partagez-la avec votre équipe, appliquez-lui des filtres, programmez-la comme rapport dans Slack ou par e-mail, publiez-la comme point de terminaison REST ou exportez les résultats vers Excel et Google Sheets. Nova peut également lire vos schémas et générer la requête si vous préférez décrire la question plutôt que d'écrire les jointures.
Vos bases de données restent où elles sont. La question n'a plus d'importance.
Indiquez deux connexions, rédigez une instruction, et consultez le plan avant de l'exécuter. Aucun pipeline, aucun entrepôt de données, aucun ticket de pare-feu.
Federated queries are on every plan, including Free
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish