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:
FROMsuggests tables,WHEREsuggests columns scoped to what's actually in your query, and it distinguishes a bare column (suggest an operator) from an already-complete condition (suggestAND/ORand 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_queryfor MySQL and Redshift connections -
dynamo_list_tables,dynamo_describe_table,dynamo_scan,dynamo_query,dynamo_get_itemfor DynamoDB, since it isn't SQL and doesn't fit the same tool shape - Write tools (
dynamo_put_itemand friends, or non-SELECTSQL) 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.1only, 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.
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.
