.NET

Legacy Features & History

OmniDB has gone through several very different lives — a university project, a Python/Django web app with a plugin ecosystem, and now a single-binary Go application. This page is the place for anything that used to exist but doesn’t anymore: what it was, why it isn’t coming back, and where to find it if you still need it. For the story of the project itself, see Introduction.

Version timeline

Era What it was
Original (ASP. NET/C#) Undergrad final project at the Federal University of Paraná — the first tool to trace a common line between PostgreSQL, MySQL/MariaDB, Oracle, SQLite, Firebird and SQL Server metadata.
OmniDB (Python/Django) The long-lived version most people know: a Django web app with a browser-based workspace and, from 2.9 onward, a Python plugin system for community extensions. Development on the original OmniDB/OmniDB repository stopped around 2020.
2025–2026 revival (3.1.x) The project was picked back up: modernized codebase, improved security, native macOS Apple Silicon support, and a full documentation overhaul — still on the Python/Django backend at this point.
Go rewrite (3.6.x) The entire backend was rewritten from Python/Django to Go and shipped as a single native binary. The Python runtime, and everything that only made sense inside it — including the plugin system — was removed.
Wails migration (done) The desktop shell moved from NW.js to Wails (Go) — a smaller binary, no bundled Chromium, and the app now drives the OS’s own native webview instead.

The plugin system (removed)

The plugin system has been removed as part of the 3.6.x rewrite of the backend from Python/Django to Go, and is no longer available.

OmniDB 2.9 introduced a plugin system that let users write Python code, hooked into different parts of the interface, to add their own features without redeploying the whole application. That mechanism depended on dynamically importing arbitrary Python modules into the running server process — something with no equivalent in a compiled Go binary — and was deliberately not carried over. Since it could never do anything useful again, the “Plugins” dialog and its menu entry, and the API endpoints behind it, were removed from the application entirely rather than kept around as a permanently-empty stub.

If you relied on a specific plugin, there is currently no supported way to port it forward. Anything a plugin used to do by calling into the database directly can usually still be done today through the regular SQL editor, snippets, or a custom monitoring unit.

PL/pgSQL step debugger (removed)

OmniDB 2.3.0 added an interactive step debugger for PL/pgSQL functions and procedures — breakpoints, live variable inspection, and per-line execution statistics. It depended on a custom PostgreSQL C extension (omnidb_plugin) hooking into PL/pgSQL’s internal plugin API, loaded via shared_preload_libraries (a server restart), plus a dedicated omnidb schema and passwordless local access for a second, debugger-only database connection.

The debugger has been removed, along with its “Debug Function”/“Debug Procedure” tree menu entries. It was never ported during the 3.6.x Go rewrite, and the omnidb_plugin extension itself hasn’t been touched since 2020. Beyond the ongoing cost of keeping a PostgreSQL-internals C extension working across every new major PostgreSQL version, it fundamentally can’t work at all against any managed/cloud PostgreSQL (RDS, Cloud SQL, Supabase, Neon, and similar) — none of them allow a custom shared_preload_libraries entry — so a large and growing share of today’s users could never have used it regardless of how well it was maintained.

Writing and running PL/pgSQL functions themselves is unaffected — see Writing PL/pgSQL Functions. If you need to step through PL/pgSQL execution against your own self-hosted PostgreSQL server, the original omnidb_plugin source is still available in the original repository’s history, or you can use pldebugger (the actively-maintained equivalent used by pgAdmin) directly, outside of OmniDB.

pglogical (removed)

pglogical was a PostgreSQL extension providing an efficient logical-replication system. The old omnidb-pglogical plugin added tree-view nodes and SQL-template actions (create node, manage replication sets, create subscriptions, and so on) for working with it — all built on the removed plugin system above, so it no longer loads.

Postgres-BDR (removed)

Postgres-BDR (“Bi-Directional Replication”) was 2ndQuadrant’s multi-master extension for PostgreSQL. The old omnidb-bdr plugin gave it the same kind of tree-view integration as pglogical. Same story: it was a plugin, and the plugin system it depended on is gone.

Postgres-XL (removed)

Postgres-XL was a massively-parallel, horizontally-scalable fork of PostgreSQL (GTM + coordinator + data nodes). The old omnidb-xl plugin added cluster-aware tree-view nodes for it. Also a plugin, also gone.

Why none of these are coming back

All three were thin, plugin-based integrations for niche, largely unmaintained-upstream PostgreSQL forks/extensions — none of pglogical, BDR or Postgres-XL saw meaningful new releases in recent years. Rebuilding the plugin system itself in Go would mean designing an entirely new extension mechanism (compiled plugins, a scripting runtime, or a hook API) for a small and shrinking audience, which hasn’t been a priority against the rest of the Go rewrite. Nothing about the rewrite prevents connecting to a pglogical/BDR/XL cluster as a plain PostgreSQL database and managing replication objects by hand through the regular SQL editor or Console tab — you simply don’t get the dedicated tree-view nodes and SQL-template shortcuts the plugins used to add.

Where to find the old releases

Releases of classic OmniDB (up to ~2020) with full plugin support are still available, unmaintained, from the original repository:

Neither repository receives updates. If you need pglogical, BDR or Postgres-XL management today, an old release from there — run against a database matching its era — is your best option; there’s no migration path from that setup into the current Go-based OmniDB.