DEV Community: Cristian Carlos dos Santos

Letting AI agents query my databases without ever giving them the credentials

Cristian Carlos dos Santos — Tue, 20 Oct 2026 00:13:54 +0000

Every time I connect an AI agent to a database, the same question comes up: where does the connection string live? Usually the answer is "in the agent's config file", which means a password sitting in a JSON file next to a tool I don't fully control.

I took a different route in omni-sql, an open-source desktop SQL IDE. The IDE already holds my connections (passwords live in the OS keyring). It also runs a local MCP server, so the agent talks to the IDE, not to the database.

How it works

The MCP server runs over STDIO on loopback. The agent never receives a host, user, password or connection string.
Reads (getSchemaSummary, getTableIndexes, explainSql, getLatestSqlExecutionError) work on the connection of the active tab only. There is no tool to list or open other connections.
Writes are never automatic. proposeSqlEdit shows a before/after diff in the desktop. executeSql shows the connection and the exact SQL, and runs only after I approve; the approval is bound to that request and expires after 120 s.
Results are bounded (default 100 rows, max 1,000, 256 KiB per response).

What this does and does not protect

It removes the credential from the agent's configuration. It does not hide data: SQL, schema names and permitted results are visible to the connected MCP client, so use it only when that exposure is acceptable. Approved SQL can still change data, so I use a least-privilege database user for anything important.

Why a desktop approval step

An agent that can run arbitrary SQL on its own is a bigger risk than one that has to ask. The approval dialog keeps a human in the loop for the one action that matters.

Also new since my last post

MongoDB (native queries plus read-only SQL via DuckDB), local analysis with DuckDB, CSV/S3 imports and macOS installers (v0.14.0).

Repo and docs: github.com/cccadet/omni-sql (see docs/MCP.md).

Question for readers: would you trust this model for a staging database, and what would you want the approval dialog to show?

Querying CSV and Parquet exports inside a SQL IDE with DuckDB

Cristian Carlos dos Santos — Tue, 06 Oct 2026 22:43:17 +0000

Someone sends you a CSV export and asks you to investigate it. You need to check duplicates, group records, or compare it with another export. For a one-off analysis, loading it into a database or writing a separate script can take longer than the query itself.

I'm building omni-sql, an open-source SQL IDE with embedded DuckDB. You can import CSV or Parquet and query it with SQL inside the IDE. A spreadsheet someone sends you fits this workflow when exported as CSV.

Joining a file with a database query result

Sometimes the file only contains part of what you need. You can also import a database query result into local DuckDB and join it with the file, without loading the file into the source database.

The demo uses fictional sales rows from PostgreSQL and a CSV of regional targets. The sales query uses VALUES, so it doesn't create tables or change database data.

Run the sales query on PostgreSQL and send the full result to local analysis.
Import targets.csv into the local DuckDB workspace.
Run the join in the local SQL tab, using the table names shown in your workspace.

This GIF is a sequence of app screenshots showing the workflow.

The example names the imported query result local_analysis and the CSV table targets. The join is:

SELECT
  s.region,
  s.revenue,
  t.target,
  s.revenue - t.target AS gap,
  ROUND(100.0 * s.revenue / t.target, 1) AS target_pct
FROM local_analysis AS s
JOIN targets AS t USING (region)
ORDER BY gap DESC;

The result shows South reaching 84% of its target. The SQL, CSV, instructions, and expected result are in the repository.

Trying it with your own export

The app runs locally and doesn't require an account. It is MIT licensed, with installers for Windows x64, Debian/Ubuntu amd64, and macOS 15+ on Apple Silicon and Intel. Node.js and Java runtimes are bundled. The macOS builds use ad-hoc signing and are not notarized; the README explains the first launch.

The project is still early. Full imports have resource limits, and an imported sample only supports conclusions about that sample. The local analysis guide covers those limits and numeric precision constraints.

Source code and downloads

How do you investigate files people send you today? If you try omni-sql, I'd like to hear whether you could import and query a file, and what was missing. There's also a first-run feedback form for compatibility and installation reports.

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

Update (Oct 2026): this post describes v0.2.5. Since then omni-sql added MongoDB support (native queries and read-only SQL), local DuckDB analysis, S3/CSV imports, a local MCP bridge and macOS installers (now v0.14.0). MongoDB is no longer deferred.

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.