vi-sql and the Return of Keyboard-First Database Work

The database client is becoming a workspace

A database terminal used to mean a prompt, a query, and a stream of rows. That model remains dependable, but it asks users to remember schema details, juggle output formatting, and reach for separate tools when a query plan or table relationship matters. Full graphical clients solve those problems with persistent panels and rich inspectors, yet they can feel detached from a terminal-centered development loop.

vi-sql occupies the increasingly interesting space between those poles. It is a full-screen terminal interface with a schema browser, SQL editor, result tables, query-plan views, import and export tools, and connection profiles. Its defining choice is keyboard control: Vim and conventional profiles are included, bindings are remappable, and a command palette makes less-familiar actions discoverable. The result is not simply psql with color. It is an attempt to make database exploration feel like navigating an editor.

A genuinely young client

The upstream repository was created on February 27, 2026, and the project published stable release v0.1.0 on June 2. That makes vi-sql a clear fit for a newer-tool slot, but the date should calibrate expectations as much as generate interest. Its release history is active, and the current documentation lists PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle, DuckDB, CockroachDB, Turso, TiDB, and Redshift support. Breadth on a feature list is not the same as years of compatibility testing across each engine.

The public launch discussion provides unusually useful evidence of actual use. Readers asked about SQLite files, SSH tunneling, exports, and comparisons with Vim-oriented alternatives. One user traced a navigation problem to tmux intercepting Ctrl-h; another reported differences between vi-sql's word motion and Neovim's. The maintainer responded with fixes and described rewriting motion behavior. That exchange is more informative than a download badge: people tried real combinations, found boundaries, and fed them back into the project. It also shows why “Vim mode” is a demanding promise rather than a checkbox.

What it brings into one screen

The appealing workflow is compact:

• browse schemas and inspect DDL without leaving the terminal;
• compose SQL with highlighting and completion;
• examine results, export them, or open an EXPLAIN view;
• switch among saved connections through the same keyboard model.

For someone moving repeatedly between source code, logs, and a development database, reducing application switching can preserve context. Custom themes and bindings matter here less as decoration than as integration: the client can fit an existing terminal setup instead of demanding a second interaction language.

There are two boundaries worth keeping visible. First, a terminal multiplexer, shell, editor, and database client all compete for a limited set of keys. Remapping is necessary, but teams should document the resulting profile rather than assume defaults work everywhere. Second, connection convenience concentrates credentials. vi-sql documents encrypted storage through an operating-system keyring or an Argon2id-protected master password. That is preferable to plaintext, but it does not replace least-privilege accounts, short-lived credentials where available, or separate production and development identities.

MCP changes the risk calculation

vi-sql also includes a Model Context Protocol server, allowing compatible assistants to inspect or query configured databases. This can shorten the route from “why did this request fail?” to examining relevant data, but it also changes who can initiate a query. A helpful agent can misunderstand scope as easily as a person can paste SQL into the wrong connection.

Start with a disposable database or a read-only replica. Limit exposed connections, inspect the tool descriptions the agent receives, and keep destructive operations outside the first evaluation. Logs should make it possible to distinguish queries run by a person from those initiated through an agent. Convenience is not a permission model. The MCP feature deserves a separate security decision from adopting the interactive client itself.

Choosing the right level of interface

vi-sql is not automatically a replacement for every database tool. mycli is a mature choice when the job is primarily interactive MySQL and completion at a traditional prompt. DBX moves in the other direction, offering a graphical surface across many SQL and non-SQL systems, plus schema comparison and data-transfer features. Native clients remain the conservative option for engine-specific scripting, recovery, and operational procedures.

A sensible evaluation uses a sanitized database and a representative task: find a table, inspect its definition, write a join, review the plan, and export a small result. Note where completion helps, where keybindings collide, and whether output remains legible for wide or nested data. Then repeat with a read-only remote connection.

vi-sql's strongest argument is not novelty alone. It makes a database feel close to the rest of a keyboard-driven workflow while retaining enough visual structure to explore unfamiliar schemas. Its youth, multi-engine ambition, and agent integration are also reasons to adopt it deliberately. If the interface reduces friction without weakening credential boundaries or query review, it can earn a place beside—not necessarily instead of—the native client.