What I added to omni-sql after v0.2.5: local analytics, S3, and more

Cristian Carlos dos Santos — Tue, 29 Sep 2026 18:45:32 +0000

My first post about omni-sql covered the SQL editor, five database engines, and contextual autocomplete. Since v0.2.5, I've added workflows that let me do more with the data after running a query. The current published release is v0.5.1.

Analyze data locally with DuckDB

I can send a query from the main editor to Analyze locally, check the SQL before importing it, and load either the complete result or an explicit sample. I can also start with a CSV or Parquet file. Each source becomes a dataset in a local DuckDB workspace, where I can join data from different connections and files with SQL.

The analysis editor completes dataset and column names and can suggest joins from imported foreign-key metadata. Datasets can be added, renamed, and removed without starting over. Local datasets are kept across app restarts, so an analysis can continue later.

The result grid is only a preview of the analysis. I can page through the result and export the complete query result as CSV or Parquet. Exports also include a .omni.json file with the datasets, source coverage, and ingestion times. That makes it easier to tell later whether an export came from full sources or samples.

Query S3 data in the same workspace

S3 connections now appear in the main IDE. I can browse buckets and supported CSV and Parquet objects, and query them with the SQL editor. Delta and Iceberg tables are supported when the required DuckDB extensions are available. S3 table names and columns also appear in editor completion.

I can import a bounded result from another configured database into a local dataset and join it with S3 data. For S3 setups that use DuckLake, the object browser can discover catalogs backed by a saved PostgreSQL connection or a SQLite/DuckDB file.

A few changes in the day-to-day SQL workflow

In a JOIN ... ON clause, autocomplete can suggest predicates based on foreign keys and the aliases in the query.
From a foreign-key value in query results, I can navigate to its referenced row.
/catalog opens a searchable list of SQL commands and inserts a template into the editor.
Generic ODBC connections are available alongside the existing adapters; they require a compatible driver installed on the machine.
PostgreSQL and MySQL tables can show catalog-backed DDL. Other engines show a labeled partial definition built from cached metadata.
On Windows, signed updates can be installed from inside the app.

omni-sql remains an open-source desktop project. If you work across databases or query files in S3, I'd like to hear which of these workflows would save you time and where they still fall short.

Source and documentation · Download v0.5.1

How I built one open-source SQL workspace for five database engines

Cristian Carlos dos Santos — Thu, 10 Sep 2026 17:26:38 +0000

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.

DEV Community: Cristian Carlos dos Santos