Working with more than one database engine often means maintaining more than one workflow. The SQL is familiar, but the editor, schema browser, result grid, shortcuts, and packaging expectations keep changing. Even small differences accumulate when you move between PostgreSQL, MySQL, SQL Server, and Oracle throughout the week.
I built omni-sql to explore a narrower idea: one focused desktop SQL workspace that behaves consistently across the major relational databases, without trying to become a complete administration suite.
What omni-sql does today
omni-sql currently supports PostgreSQL, MySQL, MariaDB, SQL Server, and Oracle through native adapters. A generic JDBC adapter is also available experimentally, with a more limited feature set.
The main workflow includes:
- browsing schemas, tables, columns, keys, indexes, views, and functions;
- writing SQL in a Monaco-based editor;
- completing metadata objects and columns projected by CTEs;
- running statements and inspecting messages or results;
- filtering, sorting, paging, and exporting result data;
- editing rows only when a primary-key check establishes a safe update path;
- inspecting supported execution plans.
The app runs locally and does not require an account. Connections, cached metadata, queries, and results remain in the desktop workflow rather than being sent to a hosted service.
Contextual completion without an LLM
The autocomplete system combines two kinds of context.
The first comes from database metadata. Each adapter exposes a unified model for catalogs, schemas, tables, columns, and related objects. That metadata is cached in a local SQLite database and matched against the editor's current SQL context.
The second comes from the query itself. CTE names and projected columns need statement scope, not just a global list of database objects. omni-sql delegates that resolution to a Kotlin sidecar built with Apache Calcite. If the sidecar is unavailable, times out, or cannot parse the current query, completion falls back to the metadata-based tier.
There is intentionally no LLM in this path. Suggestions should be deterministic, fast, and explainable from the schema and SQL text already on the user's machine.
Why this architecture?
The desktop shell uses Tauri, React, Fluent UI, and Monaco. Database execution and adapter logic live in a Node/TypeScript backend, while the Calcite-based scope resolver runs as a JVM sidecar.
This is not the smallest possible stack, but each part has a clear role:
- Tauri provides the native desktop shell and packaging;
- React and Fluent UI provide the application interface;
- Monaco provides a mature editing surface;
- TypeScript keeps the protocol, adapters, and UI contracts aligned;
- Calcite provides a real SQL parser and scope model for contextual completion.
Release installers bundle the Node and Java runtimes, so users do not need to assemble this toolchain themselves.
What I learned from supporting multiple engines
A shared interface does not mean pretending every database behaves identically. The useful abstraction is a common workflow with explicit dialect boundaries.
The adapters share contracts for connection management, metadata, execution, and cancellation, but vendor-specific capabilities remain visible. PostgreSQL uses EXPLAIN (FORMAT JSON), while SQL Server obtains plans through SET SHOWPLAN_XML in a separate transaction. Inline editing is available only when a primary key provides a safe update path. Generic JDBC stays experimental because a generic connection alone does not provide the same depth of metadata and execution support.
That approach is less magical, but it makes unsupported behavior easier to explain and safer to extend.
What changed through v0.2.5
The v0.2 series has focused on making the desktop workflow more coherent and easier to diagnose:
- table structure editing now follows a more unified flow;
- execution history is easier to scan and reuse;
- the active connection and database context are more visible;
- responsive behavior and dialog hierarchy are more polished;
- Java and release-verification failures are surfaced more clearly;
- SQL terminology is more consistent across the interface;
- table and index editing provide searchable choices and reviewable SQL;
- connection schema selection works better with large schema lists;
- SQL formatting preserves comments and string literals;
- CSV exports report the number of saved rows and provide direct file actions.
Version 0.2.4 also documented and refined the local MCP bridge. It lets compatible AI clients inspect safe editor and schema context or propose SQL edits, but it cannot read credentials, access arbitrary files, execute SQL, or bypass the desktop approval flow.
Version 0.2.5 is the current release containing the improvements above. Its smaller changes—safer CSV file actions, comment-safe formatting, and more reliable connection reordering—reflect the kind of practical polish the project currently needs.
Deliberate limitations
omni-sql is early-stage software and remains intentionally focused. It does not yet aim to match the breadth of mature database administration tools.
macOS and ARM installers are not currently published. Generic JDBC has limited metadata and execution support. MongoDB is deferred, and some deeper vendor-specific administration workflows remain outside the present scope.
Those boundaries are useful: they keep the project centered on the editing, navigation, execution, and result-inspection loop.
Try it and help shape the scope
Ready-to-run installers are available for Windows x64 and Debian/Ubuntu amd64. Because the project is still early, use a development database first.
Feedback about completion quality, cross-database behavior, packaging, and the chosen product boundaries would be especially helpful.
Top comments (0)