Pourquoi QoreDB ne traduit pas les requêtes entre moteurs

Quand on construit un client de base de données multi-moteurs, la tentation est forte de proposer un langage unifié. Un SQL universel qui fonctionnerait partout, de PostgreSQL à MongoDB en passant par Redis. L'idée séduit sur le papier. En pratique, elle produit des abstractions fragiles qui masquent le comportement réel de chaque moteur.

QoreDB a fait le choix inverse dès le départ. Chaque requête est envoyée telle quelle au moteur cible. Pas de traduction, pas de réécriture, pas de couche d'abstraction entre ce que le développeur écrit et ce que la base reçoit. Voici pourquoi.

Chaque moteur a sa propre grammaire

PostgreSQL et MySQL partagent une syntaxe SQL en surface, mais divergent profondément dès qu'on dépasse le SELECT basique. Les fonctions de fenêtrage, les CTE récursifs, les types JSON, les expressions régulières, la gestion des schémas : chaque moteur a ses propres conventions, ses propres mots-clés, ses propres comportements implicites.

MongoDB n'est même pas dans le même paradigme. Son langage de requête est un pipeline d'agrégation JSON, pas du SQL. Redis fonctionne par commandes clé-valeur. Prétendre traduire un SELECT JOIN PostgreSQL en pipeline MongoDB serait au mieux approximatif, au pire silencieusement incorrect.

Un développeur qui travaille avec PostgreSQL connaît PostgreSQL. Il s'attend à écrire du PostgreSQL et à obtenir un comportement PostgreSQL. Lui servir une traduction approximative, c'est lui retirer le contrôle sur ce qui s'exécute réellement.

L'unification se fait au bon niveau

Ne pas traduire les requêtes ne signifie pas que tout est cloisonné. QoreDB unifie l'expérience à un niveau structurel, pas syntaxique. Le trait DataEngine en Rust définit une interface commune que chaque driver implémente : connexion, déconnexion, listage des namespaces, des collections, exécution de requêtes, streaming de résultats. Cette interface permet à l'UI d'offrir une navigation cohérente entre tous les moteurs sans jamais toucher à la requête elle-même.

Le modèle de données utilise trois concepts universels : Namespace, Collection, Record. Un schéma PostgreSQL et une database MongoDB sont tous deux des Namespaces. Une table et une collection sont des Collections. Cette abstraction minimale suffit à construire un arbre de navigation unifié, un système d'onglets cohérent, et des panneaux de métadonnées qui fonctionnent partout.

Le contrat est clair : QoreDB unifie la navigation et l'affichage, pas le langage de requête.

Ce que la transparence apporte au quotidien

Quand un développeur exécute une requête dans QoreDB, il sait exactement ce qui part vers le serveur. Si la requête échoue, le message d'erreur vient directement du moteur, pas d'une couche intermédiaire qui aurait reformulé la requête et produit une erreur incompréhensible. Le debugging reste direct.

L'autocomplétion de l'éditeur SQL est elle aussi contextuelle. Elle propose les fonctions et la syntaxe du moteur connecté, pas un sous-ensemble générique. Les templates de requêtes sont adaptés à chaque driver. Un INSERT template pour PostgreSQL utilise RETURNING *, celui pour MySQL non, parce que MySQL ne le supporte pas.

Cette fidélité au moteur se retrouve aussi dans les fonctionnalités exposées. Le trait DataEngine utilise des implémentations par défaut pour les capacités optionnelles. Si un moteur ne supporte pas les routines ou les séquences, le driver ne prétend pas les supporter. L'interface s'adapte : les entrées de menu disparaissent, les panneaux ne s'affichent pas. Pas de faux bouton qui renverrait une erreur.

La fédération comme exception encadrée

QoreDB propose une fonctionnalité de fédération inter-bases qui permet de joindre des données provenant de connexions différentes. Cette fédération repose sur DuckDB comme moteur d'exécution local. Les données sont extraites de chaque source via le driver natif, puis injectées dans DuckDB pour y être jointes en SQL standard.

C'est la seule situation où QoreDB exécute du SQL qui n'est pas celui du moteur source. Et cette exception est explicite : l'utilisateur sait qu'il est dans un contexte de fédération, avec ses propres règles. La requête originale de chaque source reste intacte. DuckDB opère uniquement sur les résultats récupérés, pas sur les bases distantes.

En pratique : un éditeur qui respecte le moteur

Connecté à PostgreSQL, l'éditeur propose la syntaxe PostgreSQL. Connecté à MongoDB, il bascule sur un éditeur JSON avec support de la syntaxe d'agrégation. L'annulation de requête utilise pg_cancel_backend sur PostgreSQL, KILL QUERY sur MySQL, et un mécanisme best-effort sur MongoDB. L'export de données utilise les types natifs de chaque moteur.

Chaque interaction reflète le fonctionnement réel du moteur sous-jacent. Le développeur peut copier une requête depuis QoreDB, la coller dans un terminal psql ou mongosh, et obtenir exactement le même résultat. Il n'y a pas de vendor lock-in au niveau du langage.

Un choix de confiance envers le développeur

Ne pas traduire les requêtes est un choix de confiance. QoreDB part du principe que le développeur connaît son moteur et veut un outil qui l'aide à travailler plus vite avec, pas un outil qui s'interpose entre lui et sa base. L'intelligence du produit se concentre sur ce qui entoure la requête : la navigation, l'autocomplétion, la sécurité, l'affichage des résultats, l'export. La requête elle-même reste le territoire du développeur.

C'est cette posture qui permet à QoreDB de supporter des moteurs aussi différents que PostgreSQL et Redis dans la même application, sans compromis sur la fidélité de chacun.