data-peek: an Electron SQL client that opens in under two seconds and ships an MCP server

The problem data-peek targets: opening a database without opening an IDE

Most SQL clients grow into platforms. They add migration runners, schema diff engines, team workspaces and a plugin market, and the cost of that growth is startup time and memory. data-peek takes the opposite position. The README describes it as "a minimal, fast SQL client desktop application with AI-powered querying. Built for developers who want to quickly peek at their data without the bloat." The stated performance target is explicit: opens in under 2 seconds, low memory footprint.

That framing tells you who the tool is for. A backend developer who needs to confirm that a row landed correctly, a support engineer checking a customer record, or an on-call engineer reading a table while an incident is open. These are short sessions. The value is in the time between clicking the icon and seeing rows, not in the breadth of the feature tree.

The four supported engines are PostgreSQL, MySQL, Microsoft SQL Server and SQLite. That covers the common transactional stores in small and mid-sized product teams. It does not cover analytics warehouses, and nothing in the README suggests columnar or warehouse connectors are planned. If your data lives in a warehouse, this is the wrong client.

How the pieces fit: Electron shell, local credential store, MCP server on 127.0.0.1:4722

The repository's topics list electron and typescript, and the feature set is consistent with an Electron application: a Monaco-based query editor, multi-window support, and a desktop command palette bound to Cmd+K. The renderer holds the editor and grids; the main process is where the interesting constraints live.

Credentials are encrypted locally using the OS keychain, and the README states there is no telemetry. That is the right default for a client that will hold production connection strings. The audit log follows the same local-first pattern: it is a hash-chained record of every executed statement, off by default, with CSV and JSON export and an integrity verification step. The README is candid that the SQL text can contain data values, which is the honest way to describe an audit trail that records statements rather than just metadata.

The MCP server is the most architecturally specific part. It runs as a streamable HTTP server on 127.0.0.1:4722, the port is configurable, it is secured with a bearer token, and it is off by default. Read-only tools are list_connections, list_schemas, run_query and explain_query. run_query carries a 500-row cap, is wrapped in a rollback, and on Postgres additionally runs READ ONLY at the database level. Writes go through execute_statement, which raises an in-app Approve or Reject dialog per write and auto-rejects after 60 seconds. Layering a rollback wrapper, a Postgres-level read-only mode and a row cap is defence in depth, and the 60-second auto-reject is a sensible default for an agent that has stalled.

The bring-your-own-agent feature added in v0.29.0 points the assistant at a locally installed Claude Code, Codex or Antigravity (agy) CLI. data-peek never stores a key in that mode, and the README notes that Claude Code grounds answers against the live database via MCP, while Codex and Antigravity grounding waits on headless tool approval upstream. That last clause is a real limitation stated plainly by the project.

Installing data-peek and wiring up the MCP server

The README does not include a build-from-source block, so the practical path is the release assets. The releases list shows v0.29.0, v0.28.3 and v0.28.2, with v0.29.0 tagged "Bring your own agent" and v0.28.2 tagged "Schemas, and AI that acts". The repository also carries a homepage at datapeek.dev. Treat the release page and the homepage as the install instructions rather than guessing at a package manager command.

Once running, the settings you will actually touch are these. Under Settings, the MCP server section holds a ready-made claude mcp add snippet that you can copy directly. That is the one-command setup the README advertises, and it is the least error-prone way to register the server. The default endpoint is 127.0.0.1:4722 and the port is configurable, so if something else already holds 4722 you change it there and update the client snippet to match. The server is off by default and uses a bearer token, so enabling it is a deliberate two-step action.

For a PostgreSQL connection, the Default Schema feature pins search_path and focuses the sidebar on a single schema. On a database with many schemas this is the difference between a usable sidebar and a scroll hunt.

For the AI assistant, the provider list is OpenAI, Anthropic, Google, Groq and local Ollama models, all bring-your-own-key. If you are not comfortable sending schema and query text to a hosted provider, Ollama is the only listed option that keeps inference local, and the bring-your-own-agent mode avoids storing a key at all by reusing an existing CLI sign-in.

Two other keybindings are worth memorising because they are the entry points to features you will otherwise forget exist: Cmd+K for the command palette, and Cmd/Ctrl+Shift+H to open the Time Machine timeline strip.

Watch Mode and Time Machine: the two features that change how you read a table

Watch Mode re-runs a read-only query on a cadence from 500ms to 5 minutes and highlights what changed. Changed cells flash amber, new rows arrive with a green band that fades over a configurable window, and a tab-bar dot keeps pulsing on watched tabs so you can switch away and still see activity. The design detail that matters is row keying: diffs survive sorting and pagination by keying on explicit primary keys first, then a heuristic id, uuid or *_id column, then row position. That ordering is a reasonable fallback chain, but the third tier is positional, which means a diff on a keyless table can misreport changes if the underlying order shifts. The README does not claim otherwise.

The other detail is a gate rather than a feature. Before execution, Watch Mode refuses INSERT, UPDATE, DELETE, DDL, transaction and multi-statement queries, with a tooltip explaining why. A polling client that can mutate is a footgun, and blocking it at the query-parsing stage is stronger than a warning dialog. Watch Mode also pauses when the window is hidden, so background tabs do not hammer the database.

Time Machine snapshots successful SELECT results locally and lets you scrub back through past runs. Any past run loads read-only behind a "viewing the past" banner with a row-count sparkline, and you can diff any two runs with cell-level highlights plus added and removed row counts, keyed the same way Watch Mode keys. The privacy handling is described concretely: masked columns are stored redacted, storage is capped at 50 runs per query and a 512 MB global budget, and Settings has a one-click wipe. Storing query results on disk is a real exposure, and the project treats it as one. If your result sets contain regulated data, the masking rules are the control you need to configure before enabling this, not after.

Where data-peek stops: no migrations, thin licence clarity, and a young release cadence

The Table Designer creates and alters tables with full DDL support covering columns, indexes, constraints and partitions. The Triggers view lets you alter, enable, disable or drop triggers from the schema sidebar. What is absent from the README is any migration story: no versioned migration files, no environment promotion, no drift detection between a staging and production schema. That is a deliberate boundary, and it means data-peek complements a migration tool rather than replacing one. If your workflow depends on reviewing a generated migration before it runs, this client will not give you that.

The licence is listed as NOASSERTION. That is the repository metadata telling you the licence could not be automatically classified, not a statement that the project is unlicensed. It does mean you cannot determine your obligations from the metadata alone. If you are evaluating this for a company, read the actual licence file in the repository before you install it anywhere that matters. Nothing here is legal advice, but an unclassified licence is a procurement blocker in plenty of organisations, and it is better to find that out before a rollout than after.

Release cadence is worth noting without reading anything into download counts. The tags show v0.28.2 and v0.28.3 within a day of each other in early August 2026, then v0.29.0 a few days later. Patch releases arriving that close together suggests active iteration, and it also suggests you should not pin to a patch version and forget it. The 0.x version number is the project's own signal that interfaces and behaviour can still move.

The AI assistant has a dependency the README does not resolve: schema-aware query generation needs your schema, and bring-your-own-key means that schema goes to whichever provider you configure. For teams with strict data-egress rules, the assistant is the part to leave off, and the rest of the client works without it.

How data-peek differs from DBeaver and pgAdmin

DBeaver is the obvious comparison for anyone shopping for a free multi-database client. The difference is scope. DBeaver is a general-purpose database IDE with a JDBC driver layer that reaches dozens of engines, plus data transfer, schema comparison and a plugin system. data-peek supports four engines and spends its complexity budget on interaction speed and on features that only make sense in a desktop app, like Watch Mode's amber cell flashes and Time Machine's timeline scrubber. If you need to connect to Oracle, Snowflake and MongoDB from one window, DBeaver is the tool and data-peek is not in the conversation.

pgAdmin is the closer comparison for a Postgres-only team, and the split is different again. pgAdmin exposes server administration: roles, tablespaces, configuration files, the statistics collector. data-peek does none of that. It reads and edits data and it inspects query plans. The Performance Analysis section covers query telemetry with a timing waterfall, a benchmark mode that reports p50/p90/p99 across repeated runs, an EXPLAIN viewer with interactive node breakdown, and a performance indicator that flags missing indexes, N+1 patterns and slow queries with suggested fixes. That is developer-facing diagnosis, not DBA-facing administration.

The MCP server is where data-peek has no direct equivalent in either tool. Exposing list_connections, list_schemas, run_query and explain_query to an agent over streamable HTTP on 127.0.0.1:4722, with writes gated behind an in-app approval dialog and a 60-second timeout, is a specific answer to a question the older clients have not had to address. Whether that matters to you depends entirely on whether you already run a coding agent against your database, and if you do not, the MCP server is dead weight you leave switched off.

Upgrade cost and what to verify before you standardise on data-peek

Because the project is pre-1.0 and shipping patches days apart, the upgrade cost is not a migration script. It is the habit of checking release notes before bumping, particularly for anything touching the MCP server tools, the Watch Mode mutation gate, or the Time Machine storage caps. Those three areas define the contract between the app and your database, and a change in any of them changes what the tool can do to your data.

There is also a configuration surface that persists across upgrades: connection credentials in the OS keychain, saved queries with folders and tags, and Time Machine snapshots capped at 50 runs per query and 512 MB globally. Credentials and snapshots survive on disk. If you are testing the tool on a shared machine, the one-click wipe in Settings is the control for the snapshot store, and the keychain entry is the control for credentials.

What to verify first, in order. Read the licence file, because NOASSERTION metadata is not an answer. Confirm the MCP server defaults by opening Settings and checking the bind address and bearer token before you enable it, since the server is off by default and enabling it is the moment your database becomes reachable from a local agent. Decide which AI provider you will configure, or whether you will configure none, because the assistant and the bring-your-own-agent mode both depend on that choice and both change what leaves your machine. Finally, test the Watch Mode gate against a query you know is a mutation. If it refuses, the gate is working; if it does not, stop and read the release notes for your version before trusting the client with a production connection.

Editorial conclusion

Adopt data-peek if you want a fast read-and-poke client for Postgres, MySQL, SQL Server or SQLite and you specifically want to hand read-only database access to a coding agent through the MCP server. Skip it if you need a GUI that manages migrations, orchestrates schema changes across environments, or if your team cannot accept an unresolved licence. Before installing, check the licence text in the repository, read the MCP server section of Settings to confirm the bearer token and bind address defaults, and verify which features are gated behind the AI provider you intend to use.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Rohithgilla12/data-peek on GitHub