Anciennes fonctionnalités et historique

OmniDB a connu plusieurs vies très différentes — projet universitaire, application web Python/Django dotée d’un écosystème de plugins, et aujourd’hui application Go en binaire unique. Cette page recense tout ce qui existait autrefois mais qui n’existe plus : ce que c’était, pourquoi cela ne reviendra pas, et où le retrouver si vous en avez encore besoin. Pour l’histoire du projet lui-même, voir Introduction.

Chronologie des versions

Époque	Ce que c’était
Version originale (ASP. NET/C#)	Projet de fin d’études de licence à l’Université fédérale du Paraná — le premier outil à tracer une ligne commune entre les métadonnées de PostgreSQL, MySQL/MariaDB, Oracle, SQLite, Firebird et SQL Server.
OmniDB (Python/Django)	La version de longue durée que la plupart des gens connaissent : une application web Django dotée d’un espace de travail accessible depuis un navigateur et, à partir de la version 2.9, d’un système de plugins Python pour les extensions communautaires. Le développement sur le dépôt d’origine OmniDB/OmniDB s’est arrêté vers 2020.
Relance 2025–2026 (3.1.x)	Le projet a été repris : base de code modernisée, sécurité améliorée, support natif d’Apple Silicon sur macOS, et refonte complète de la documentation — tout en restant, à ce stade, sur le backend Python/Django.
Réécriture en Go (3.6.x)	L’ensemble du backend a été réécrit de Python/Django vers Go et livré sous forme de binaire natif unique. L’environnement d’exécution Python, et tout ce qui n’avait de sens qu’à l’intérieur de celui-ci — y compris le système de plugins — a été supprimé.
Migration vers Wails (terminée)	La coquille de l’application de bureau est passée de NW.js à Wails (Go) — un binaire plus petit, sans Chromium embarqué, l’application pilotant désormais directement la webview native du système d’exploitation.

Le système de plugins (supprimé)

Le système de plugins a été supprimé lors de la réécriture 3.6.x du backend de Python/Django vers Go, et n’est plus disponible.

OmniDB 2.9 a introduit un système de plugins permettant aux utilisateurs d’écrire du code Python, branché sur différentes parties de l’interface, afin d’ajouter leurs propres fonctionnalités sans redéployer l’ensemble de l’application. Ce mécanisme reposait sur l’importation dynamique de modules Python arbitraires dans le processus serveur en cours d’exécution — une chose sans équivalent dans un binaire Go compilé — et n’a délibérément pas été repris. Comme il ne pouvait plus jamais servir à rien d’utile, la fenêtre « Plugins» et son entrée de menu, ainsi que les points d’entrée d’API qui la sous-tendaient, ont été entièrement retirés de l’application plutôt que conservés en tant que module définitivement vide.

Si vous dépendiez d’un plugin particulier, il n’existe actuellement aucun moyen pris en charge de le porter. Tout ce qu’un plugin faisait en interrogeant directement la base de données peut généralement encore se faire aujourd’hui via l’éditeur SQL classique, les extraits de code (Snippets), ou une unité de supervision personnalisée.

Débogueur pas à pas PL/pgSQL (supprimé)

OmniDB 2.3.0 a ajouté un débogueur pas à pas interactif pour les fonctions et procédures PL/pgSQL — points d’arrêt, inspection des variables en direct et statistiques d’exécution ligne par ligne. Il reposait sur une extension C PostgreSQL personnalisée (omnidb_plugin) se branchant sur l’API interne de plugin de PL/pgSQL, chargée via shared_preload_libraries (nécessitant un redémarrage du serveur), ainsi que sur un schéma omnidb dédié et un accès local sans mot de passe pour une seconde connexion à la base de données réservée au débogueur.

Le débogueur a été supprimé, ainsi que ses entrées de menu contextuel « Debug Function»/« Debug Procedure». Il n’a jamais été porté lors de la réécriture 3.6.x en Go, et l’extension omnidb_plugin elle-même n’a pas été modifiée depuis 2020. Au-delà du coût permanent de maintenir en état de marche une extension C touchant aux mécanismes internes de PostgreSQL à travers chaque nouvelle version majeure, elle ne peut fondamentalement pas du tout fonctionner sur une instance PostgreSQL managée/cloud (RDS, Cloud SQL, Supabase, Neon, et similaires) — aucune d’entre elles n’autorise d’entrée personnalisée dans shared_preload_libraries — de sorte qu’une part importante et croissante des utilisateurs actuels n’aurait de toute façon jamais pu l’utiliser, quelle que soit la qualité de sa maintenance.

L’écriture et l’exécution de fonctions PL/pgSQL elles-mêmes ne sont pas affectées — voir Écrire des fonctions PL/pgSQL. Si vous avez besoin de déboguer pas à pas l’exécution de PL/pgSQL sur votre propre serveur PostgreSQL auto-hébergé, le code source original d’omnidb_plugin reste disponible dans l’historique du dépôt d’origine, ou vous pouvez utiliser directement pldebugger (l’équivalent activement maintenu utilisé par pgAdmin), en dehors d’OmniDB.

pglogical (supprimé)

pglogical était une extension PostgreSQL fournissant un système de réplication logique efficace. L’ancien plugin omnidb-pglogical ajoutait des nœuds d’arborescence et des actions basées sur des modèles SQL (créer un nœud, gérer les ensembles de réplication, créer des abonnements, etc.) pour travailler avec elle — le tout construit sur le système de plugins supprimé ci-dessus, il ne se charge donc plus.

Postgres-BDR (supprimé)

Postgres-BDR (« Bi-Directional Replication») était l’extension multi-maître de 2ndQuadrant pour PostgreSQL. L’ancien plugin omnidb-bdr lui offrait le même type d’intégration dans l’arborescence que pglogical. Même histoire : c’était un plugin, et le système de plugins dont il dépendait a disparu.

Postgres-XL (supprimé)

Postgres-XL était un fork massivement parallèle et à mise à l’échelle horizontale de PostgreSQL (GTM + coordinateur + nœuds de données). L’ancien plugin omnidb-xl ajoutait des nœuds d’arborescence adaptés au cluster. Également un plugin, également disparu.

Pourquoi rien de tout cela ne reviendra

Les trois étaient des intégrations légères, basées sur des plugins, pour des forks/extensions PostgreSQL de niche, dont le développement amont était largement à l’arrêt — ni pglogical, ni BDR, ni Postgres-XL n’ont connu de nouvelles versions significatives ces dernières années. Reconstruire le système de plugins lui-même en Go impliquerait de concevoir un tout nouveau mécanisme d’extension (plugins compilés, environnement de script, ou API de hooks) pour un public restreint et en déclin, ce qui n’a pas été jugé prioritaire face au reste de la réécriture en Go. Rien dans cette réécriture n’empêche de se connecter à un cluster pglogical/BDR/XL en tant que simple base de données PostgreSQL et de gérer les objets de réplication à la main via l’éditeur SQL classique ou l’onglet console — vous perdez simplement les nœuds d’arborescence dédiés et les raccourcis de modèles SQL que les plugins ajoutaient autrefois.

Où trouver les anciennes versions

Les versions de l’OmniDB classique (jusqu’à ~2020), avec la prise en charge complète des plugins, restent disponibles, sans maintenance, sur le dépôt d’origine :

github.com/OmniDB/OmniDB — l’application d’origine et ses archives de versions.
github.com/OmniDB/plugins — les sources des plugins pglogical/BDR/XL eux-mêmes.

Aucun des deux dépôts ne reçoit de mises à jour. Si vous avez besoin aujourd’hui de gérer pglogical, BDR ou Postgres-XL, une ancienne version issue de ces dépôts — exécutée contre une base de données de la même époque — est votre meilleure option ; il n’existe aucune voie de migration entre cette configuration et l’OmniDB actuel basé sur Go.