DEV Community: Shubhesh Shukla

DB Connect: a database IDE that lets your AI assistant actually query your database

Shubhesh Shukla — Fri, 14 Aug 2026 18:59:43 +0000

Most database GUIs were designed before "AI coding assistant" was a category. You'd find a bug, realize it might be a data problem, and then spend five minutes exporting a table or pasting query output into a chat window just so the assistant could see what you were looking at.

DB Connect is a free, cross-platform desktop IDE for MySQL, Amazon Redshift, and DynamoDB — built to close that gap instead of ignoring it.

The problem

Three separate frustrations, one tool:

Most GUI database clients are Electron apps — slow to start, heavy on memory, for something that's fundamentally a schema browser and a text box.
Useful features (backup/restore, user management, performance monitoring) are often paywalled or missing entirely on the free tier.
None of them know an AI coding assistant might want to look at the same database you're looking at.

What DB Connect does

It's built with Go + Wails v2 + React instead of Electron, so it starts instantly and has a tiny footprint. Beyond the query editor, it has:

Stored routine/trigger/event visibility (list procedures/functions/triggers/events, view SHOW CREATE ... definitions)
Real backup/restore via mysqldump/mysql, not just an app-config export
Full user and privilege management — create/alter/drop user, grant/revoke, built as validated SQL builders that run through the same execution path as everything else, so production/read-only safety checks always apply
Connection-string paste-to-parse, table relations (foreign keys in both directions), saved result-grid filters, a CSV import field-mapper
Native performance panes for all three engines: slow queries, live activity, lock analysis, index health — and for DynamoDB specifically, capacity/throttle/hot-partition signals with zero CloudWatch dependency
Context-aware SQL autocomplete: FROM suggests tables, WHERE suggests columns scoped to what's actually in your query, and it distinguishes a bare column (suggest an operator) from an already-complete condition (suggest AND/OR and the next column)

Where AI fits in

This is the part I think is worth a deeper look: DB Connect runs a local MCP (Model Context Protocol) server. Any MCP-aware tool — Claude Code, Cursor, others — can call it directly:

list_connections, list_databases, list_tables, describe_table, run_query for MySQL and Redshift connections
dynamo_list_tables, dynamo_describe_table, dynamo_scan, dynamo_query, dynamo_get_item for DynamoDB, since it isn't SQL and doesn't fit the same tool shape
Write tools (dynamo_put_item and friends, or non-SELECT SQL) only activate if you explicitly enable "Allow writes" — off means genuinely read-only, not read-mostly

Security posture is deliberately narrow:

Off by default — you opt in per install, it's not silently listening
Binds to 127.0.0.1 only, never any other interface
Never dials a new database connection and never returns or logs credentials — it only reaches connections you've already opened and authenticated through the app itself

In practice this means an AI assistant debugging your code can also just check the data. "Is this off-by-one actually a data problem?" stops being a question you answer by memory and becomes a query the assistant runs itself, in the same session.

Try it

# macOS, via Homebrew
brew install --cask shubhesh07/db-connect/db-connect

# macOS, no Homebrew
curl -fsSL https://github.com/shubhesh07/db-connect/releases/latest/download/install.sh | bash

Windows installers and portable builds are on the releases page.

Free forever, no telemetry, no account required.

Repo: https://github.com/shubhesh07/db-connect
Site: https://shubhesh07.github.io/db-connect

What's next

I'd genuinely like feedback on the MCP security model in particular — is off-by-default-and-localhost-only enough, or is there an appetite for an auth token even for a loopback-only server? Open an issue or find me in the repo discussions.

Why I Built a Database Client in Go Instead of Electron

Shubhesh Shukla — Sun, 03 May 2026 18:55:33 +0000

Most mornings at work I had three database tools open. DataGrip for MySQL, a Redshift-compatible client, and the AWS console for DynamoDB. That's three windows, three sets of saved credentials, three different query histories, and about 1.5GB of RAM just to look at tables.

I built DB Connect to replace all three. It's a free desktop database IDE for MySQL, Amazon Redshift, and DynamoDB. The installed binary is 18MB. It opens in under two seconds. And it does not bundle Chromium.

This post covers the technical decisions behind it — what worked, what was painful, and what I would change.

The problem

If you work at a company that runs MySQL for transactional data, Redshift for analytics, and DynamoDB for high-throughput key-value access, you know the tool fragmentation problem. Every database client either:

Supports relational databases well but ignores DynamoDB entirely
Is built on Java and takes 15 seconds to show you a cursor
Costs $25/month per seat for features you use 10% of

I wanted one tool that could connect to all three, store credentials securely, and not make my laptop fan spin up just by existing in the dock.

Why not just use what exists

I tried everything. Here's an honest comparison:

Tool	Price	Install Size	Startup	Stack	DynamoDB
DataGrip	$25/mo	~800MB	10-30s	Java/IntelliJ	No
DBeaver	Free (community)	~400MB	5-15s	Java/Eclipse	No
TablePlus	$89 (license)	~80MB	<3s	Native	Yes
DB Connect	Free	18MB	<2s	Go + Wails	Yes

DataGrip is genuinely excellent if you live in relational-only land and your company pays for JetBrains. But no DynamoDB, and the cold start time on a Monday morning is painful.

DBeaver is the community workhorse. It does a lot. It also runs on Eclipse, which means it does a lot slowly. No DynamoDB support in the free tier.

TablePlus is the closest to what I wanted — it's native, fast, and supports DynamoDB. But the DynamoDB experience is basic, it's not free, and I wanted features like EXPLAIN visualization and parameterized saved queries that it doesn't offer.

None of them solved my specific problem: a fast, lightweight, free tool that treats MySQL, Redshift, and DynamoDB as equal citizens.

The tech stack decision

The first question was Electron vs. something else. Electron is the safe choice — massive ecosystem, battle-tested, every tutorial on the internet. But Electron means bundling Chromium, which means:

400MB+ installed size minimum
150-300MB RAM just for the shell before your app does anything
A full browser process even though you're building a desktop app

I went with Wails instead. Wails uses the system's native WebView (WebKit on macOS, WebView2 on Windows) and a Go backend. The tradeoff is real: you lose some cross-browser consistency and the Chrome DevTools you're used to. But you gain a single compiled binary, native performance, and an 18MB install.

Go was a natural fit for the backend. Database drivers are mature in the Go ecosystem (database/sql, go-sql-driver/mysql, aws-sdk-go-v2). Goroutines make it trivial to run queries without blocking the UI — every query execution spawns a goroutine, and the frontend gets results via Wails' binding system. No thread pools to manage, no callback hell.

The frontend is React 18 with TypeScript. Nothing exotic. The interesting piece is Monaco — the same editor engine that powers VS Code — which gives you autocomplete, syntax highlighting, multi-cursor editing, and bracket matching without building any of that from scratch.

Architecture overview

+-----------------------------------+
|  React + TypeScript + Monaco      |  <- UI layer
|  (runs in system WebView)         |
+-----------------------------------+
|  Wails v2 bridge                  |  <- function bindings, events
+-----------------------------------+
|  Go backend                       |
|   +- Connection manager           |  <- pool management, SSH tunnels
|   +- Query executor               |  <- goroutine per query
|   +- Credential store             |  <- AES-256-GCM + OS keychain
|   +- DynamoDB client              |  <- scan/query/GetItem abstraction
+-----------------------------------+

Wails generates TypeScript bindings from Go structs and methods automatically. You export a Go method, and it becomes callable from JavaScript. No REST API, no WebSocket protocol, no serialization layer to maintain. The Go backend owns all database connections, all encryption, and all credential storage. The frontend never touches raw connection strings or passwords.

One quirk worth mentioning: PostHog analytics are routed through the Go backend as a proxy. Wails' WebView doesn't let you make arbitrary cross-origin requests the way a normal browser tab would, so the Go layer handles the HTTP calls to PostHog's ingest endpoint. It's a small thing, but the kind of thing you don't discover until you're debugging why your analytics silently fail.

The DynamoDB challenge

Most database tools ignore DynamoDB because it doesn't speak SQL and its data model is genuinely different. You can't just bolt a SQL editor onto it.

DynamoDB has partition keys, sort keys, global secondary indexes, and a type system that includes String (S), Number (N), Binary (B), List (L), Map (M), String Set (SS), Number Set (NS), and Binary Set (BS). Building a query means specifying key conditions, optional filter expressions, selecting an index, and understanding the difference between a Query (which requires a partition key) and a Scan (which reads the entire table and should terrify you in production).

DB Connect has a visual query builder that handles all of this. You pick your table, choose Query or Scan or GetItem, select a GSI if needed, build filter expressions with a form-based UI, and see results with proper type annotations.

The type system was the hardest part. A single DynamoDB item can have nested Maps containing Lists containing Maps containing Number Sets. The frontend needs to render this recursively, and the Go backend needs to marshal and unmarshal it correctly through the AWS SDK. I spent more time on DynamoDB type handling than on the entire MySQL integration.

Security decisions

Credentials are encrypted with AES-256-GCM before being stored. The encryption key lives in the OS keychain — macOS Keychain on Mac, Windows Credential Manager on Windows. Your database passwords never exist as plaintext on disk.

This matters more than people think. I've seen popular database tools that store passwords in plaintext JSON files or use reversible encoding that any script can decode. If someone gets read access to your home directory — through a compromised dependency, a shared machine, or a backup that wasn't encrypted — they get every database credential you have saved.

SSH tunnel support is built in for MySQL connections. You configure the tunnel parameters alongside your connection details, and the Go backend establishes the tunnel before connecting to MySQL through it.

Performance tricks

Three things keep DB Connect fast with large data:

Virtual scrolling. Result sets render using virtualized rows. Only the visible rows plus a small buffer exist in the DOM at any time. You can scroll through hundreds of thousands of rows without the browser choking on DOM nodes.

Goroutine-per-query. Every query execution runs in its own goroutine. The Wails event system pushes results back to the frontend when they're ready. Long-running Redshift analytics queries don't freeze the UI — you can switch tabs and run a quick MySQL lookup while waiting.

Binary size optimization. Go 1.25 with Wails produces a single binary. No JVM, no Node runtime, no native module compilation. The universal macOS build (Intel + Apple Silicon in one binary) is still under 20MB.

What I would do differently

Wails' WebView inconsistencies are real. WebKit on macOS and WebView2 on Windows don't behave identically. CSS that works perfectly on one platform occasionally needs tweaks for the other. I'd still choose Wails for the size and performance benefits, but budget time for platform-specific testing.

I underestimated the DynamoDB type system. I thought it would be a weekend project to add DynamoDB support. It took weeks. If I were starting over, I'd prototype the DynamoDB UI first since it was the riskiest piece.

Monaco is powerful but heavy for a WebView. Monaco is around 2-3MB of JavaScript. In a WebView-based app where you're optimizing for fast startup, it's noticeable. It's still worth it — rebuilding a code editor from scratch would be absurd — but I explored lighter alternatives before accepting the tradeoff.

What's next

PostgreSQL support — the most requested feature
MongoDB support — another NoSQL engine that most SQL-focused tools handle poorly
Linux builds — Wails supports Linux, I just need to set up the CI pipeline
ER diagram visualization — auto-generated from foreign key relationships
Query plan diff — compare EXPLAIN output before and after index changes

Try it out

DB Connect is free. I built it for my own workflow and am releasing it because the database tool space shouldn't require a subscription or a gigabyte of disk space for basic functionality.

Download: https://shubhesh07.github.io/db-connect/
Source: https://github.com/shubhesh07/db-connect
Runs on: macOS (Intel + Apple Silicon) and Windows

If you work with MySQL, Redshift, or DynamoDB and are tired of juggling multiple tools, give it a shot. Issues and feature requests are welcome.