GoNavi: a Wails-based database client that ships an MCP server in the same binary

The problem is not the editor, it is the runtime underneath it

Most database GUIs are Electron applications. The README makes this comparison directly, placing a Chromium plus Node runtime against Go plus a native WebView, and listing binary size, startup, and memory baseline as the three axes where the two differ. GoNavi's stated figure is a roughly 30MB class binary. That number is a claim from the project's own description and I have not measured it, but the architecture it implies is verifiable from the repository: Wails v2, Go on the backend, React 18 on the frontend, TypeScript as the primary language. Wails compiles the frontend into the Go binary and renders it in the platform's WebView rather than bundling a browser. The audience is developers who already keep a database client open all day and who have started pointing coding agents at their schemas. The README frames the second group explicitly, describing the goal as handing structured context to agents without moving passwords off the host machine.

One workbench, six categories of data source

The repository topics list the driver surface: MySQL, PostgreSQL, Oracle Database, MongoDB, Redis, Kafka, MQTT, ClickHouse, Milvus, and OceanBase. The README groups these into SQL, cache, vector, message queue, search, and time-series, and calls the result one cockpit. That breadth is the main differentiator against clients that treat Redis as an afterthought and have no concept of a Kafka topic or a Milvus collection. The workbench layout shown in the README is three panes: a connections panel on the left covering SSH and proxy settings plus drivers, a Monaco-based SQL editor in the middle with schema context and slash commands, and a virtualized data grid on the right with batch edit, export, and transaction submit or rollback. Below those sits a Go core that the diagram labels as audit, sync, MCP HTTP, and web server. The data flow is conventional for a Wails app: React calls into Go, Go holds the connection pool and the driver implementations, and results come back as structured rows for the grid. What is less conventional is that the same Go core exposes an HTTP server, which is where the agent story lives.

MCP and the AI assistant share the process with your connections

The README describes the AI integration as first-class and lists multi-provider support alongside MCP. The diagram places MCP HTTP and a web server inside the Go core, not in a separate sidecar. That design choice matters more than the feature list. An MCP server that runs in the same process as the connection pool can read schema metadata and query results without a second authentication path, and the README's phrasing about not leaking passwords off-host suggests that credentials stay in the Go process while structured context goes out. The AI assistant pane is shown with schema context attached, and the editor supports slash commands. I cannot confirm from the supplied material which providers are supported, how the MCP transport is authenticated, or whether the endpoint is bound to loopback. Those are the questions to answer before enabling it. The project also carries an MCPVault badge, which indicates a third-party health listing rather than anything about the code itself.

Getting it running: download the release, or build with Wails

The README points at the releases page for downloads and at gonavi.org for the project site, with a Quick Start section in the README itself. The default branch is dev, and the release list includes a dev-latest build labeled with a commit hash, so there is a channel for people who want the current state rather than a tagged version. Building from source means the Wails toolchain: the README credits Wails v2, Go, and React 18, and the repository carries a release workflow under .github/workflows/release.yml, which is the reference for how a binary is produced. The README does not reproduce the exact build commands in the portion available here, so treat the Wails documentation as the authority for wails build and wails dev rather than guessing at flags. Connection setup goes through the new-connection screen, which the README shows as a data-source selector, with SSH and proxy options in the connections panel for hosts that are not directly reachable. Configuration keys for the MCP HTTP endpoint are not listed in the material I have, which is a gap worth checking in the repository before you plan a deployment around it.

Pre-1.0, single maintainer, and a dev branch as the default

The version numbers tell you where this sits. v0.9.8 landed on 2026-09-10, three weeks after v0.9.7 on 2026-09-04, and the default branch is dev rather than main or master. A project that ships two releases in a week and keeps dev as the default branch is moving quickly, and the practical consequence is that anything you script against it can change between minor versions. The driver surface is also a liability in the same way it is an asset: ten data source families means ten sets of edge cases, and Oracle in particular is the kind of driver where a thin implementation shows up in type mapping and transaction behavior rather than in the connection dialog. The README does not describe a plugin API, so if you need to add a data source the project does not cover, you are reading Go source rather than writing an extension. And the sponsorship section, which asks for contact over WeChat, signals that this is a small operation rather than a company with a support desk behind it.

Against DBeaver and DataGrip: breadth versus depth

DBeaver is the obvious comparison for anyone who needs many data sources in one window, and it is built on Java and Eclipse RCP. The difference in approach is not only the runtime. DBeaver's JDBC driver model means third parties can and do write drivers for it, and its paid editions add features on top of a large community base. GoNavi's Go driver implementations are compiled in, which is why the binary stays small and why extending the driver list is a source change. DataGrip takes the opposite bet: fewer data sources, deeper per-engine intelligence, and a commercial license with JetBrains support behind it. GoNavi's bet is that the combination of a small native binary, MQ and vector data sources in the same window, and an in-process MCP endpoint is worth more than driver extensibility or vendor support. That is a defensible position for a solo developer or a small team, and a hard sell for an organization that needs a procurement path.

Apache-2.0, and what that does and does not cover

GoNavi is licensed under Apache-2.0, which permits commercial use, modification, and redistribution provided you keep the license and notice files and state significant changes. It also includes an explicit patent grant, which matters if you are embedding the client in a product. What the license does not give you is any warranty or support obligation from the maintainer, and the README's sponsorship section is a funding request rather than a support contract. If you fork GoNavi to add a driver, you are distributing a modified work and the notice requirements apply; the license text in the LICENSE file is the thing to read, not this paragraph. The upgrade cost is the more immediate concern. With releases arriving weekly on a pre-1.0 version, pinning to a specific tag and reading the release notes before moving is the difference between a working setup and a morning spent on a regression. I am not in a position to give legal advice on any of this, and the Apache-2.0 text is short enough to read directly.

Editorial conclusion

Adopt GoNavi if you want a single desktop process that both a human and a coding agent can query, and you are willing to run a pre-1.0 client against production data sources. Do not adopt it if you need a long-term support contract, a certified Oracle driver, or a client whose plugin ecosystem you can extend yourself. Before connecting anything real, check the v0.9.8 release notes for driver coverage, confirm whether credentials are stored in the OS keychain or in a local file, and read the MCP HTTP configuration to see whether the endpoint binds to localhost only.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Syngnat/GoNavi on GitHub