Manage your databases with AI agents.

Secure read-only access for AI agents, plus local write execution for operators.
Health checks. Schema browsing. Query and exec flows. MCP server included.

In active development

Latest release activity from GitHub.

Loading latest release info...

Who is it for?

Built for anyone who works with PostgreSQL databases daily.

Backend Developers

Manage connections to multiple databases across environments. Switch between dev, staging, and production without remembering connection strings.

Database Administrators

Monitor database health at a glance. Run quick connectivity checks across your entire fleet and spot issues before they become incidents.

DevOps Engineers

Integrate health checks into your workflow. Script database connectivity verification or use the TUI for interactive troubleshooting.

Features

Read-only AI workflows plus safe local execution for operators.

PostgreSQL Connections

Store and manage multiple PostgreSQL connection configs. One INI file, all your databases in one place.

Health Checks

Verify database connectivity with a single command. 5-second timeout keeps checks fast and responsive.

Interactive TUI

Full-screen terminal UI for schema browsing, query workflows, and local execute flows with explicit confirmation for destructive statements.

INI Config

Human-readable INI format for database configs. Easy to edit, version, and share across your team.

CLI & TUI Modes

Use query for read-only SQL and exec for local write/DDL operations. Same tool, two interfaces, clear safety boundary.

Local Execute Path

Run one write/DDL statement locally with databasecli exec --db <name>. Destructive operations require confirmation unless --yes is passed.

Cross-Platform

Runs on macOS, Linux, and Windows. Built with Rust for native performance on every platform.

MCP Read-Only Guardrails

MCP never exposes change commands. No exec tool, read-only SQL validation, and read-only transaction mode protect your databases by design.

Multi-Agent MCP Setup

One init command configures MCP for Claude Code, Opencode, Codex, and Cursor. Pick the agents you use, skip the rest.

How write safety works

AI agents stay read-only. Operators can run local changes with explicit controls.

Local operator execution (allowed)

$ databasecli exec --db staging \
  "INSERT INTO feature_flags (name) VALUES ('beta')"

$ databasecli exec --db staging \
  "DELETE FROM sessions WHERE expired_at < now()"
Execute DELETE on staging? [y/N]
y

MCP execution of change commands (blocked)

You:  Delete old sessions from production

Claude:  I cannot run DELETE through MCP.
        MCP is read-only by design:
        - no write tool surface
        - read-only SQL validator
        - read-only transaction mode

        I can draft the SQL for manual review:
        DELETE FROM sessions WHERE expired_at < now();

Installation

Two ways to get started.

Homebrew (macOS)

$ brew install maximgorbatyuk/tap/databasecli

# Verify installation
$ databasecli --version
databasecli x.y.z

Cargo (cross-platform)

$ cargo install databasecli

# Verify installation
$ databasecli --version
databasecli x.y.z

macOS, Linux, and Windows. Built with cargo-dist.

Usage

Talk to your databases with AI, use the CLI, or launch the TUI.

Set up MCP for your coding agent in one command

$ databasecli init

Select coding agents to configure MCP for:
(enter numbers separated by spaces, e.g. "1 3")

  1. Claude Code (.mcp.json)
  2. Opencode (opencode.jsonc)
  3. Codex (.codex/config.toml)
  4. Cursor (.cursor/mcp.json)

> 1 4

Config created at  .databasecli/databases.ini
Claude Code config created at  .mcp.json
Cursor config created at  .cursor/mcp.json

# Edit databases.ini to add your connections, then ask your AI:

Ask Claude about your database in plain English

You:  What tables do I have in the staging database?

Claude:  I found 12 tables in staging:

        users          4,832 rows    1.2 MB
        orders        18,294 rows    8.4 MB
        products       1,047 rows    0.3 MB
        payments      16,511 rows    5.1 MB
        ...

You:  Show me users who signed up this week

Claude:  Running query on staging...

        email                  created_at
        --------------------   ----------------
        alice@example.com      2026-03-25 09:14
        bob@startup.io         2026-03-24 14:33
        carol@dev.team         2026-03-23 11:07

        3 users signed up since Monday.

Explore schema and plan migrations with AI

You:  Draw me the entity-relationship diagram
       for orders, products, and payments

Claude:  Here's the ERD in Mermaid syntax:

        erDiagram
          orders ||--o{ payments : has
          orders }o--|| products : contains
          orders { int id PK; int user_id FK; ... }
          payments { int id PK; int order_id FK; ... }
          products { int id PK; text name; ... }

You:  I need to add a "discount_code" column to orders.
       What should the migration look like?

Claude:  Based on the current schema, here's a safe
        migration:

        ALTER TABLE orders
          ADD COLUMN discount_code VARCHAR(32);
        CREATE INDEX idx_orders_discount_code
          ON orders (discount_code)
          WHERE discount_code IS NOT NULL;

        The partial index keeps it lightweight since
        most orders won't have a discount code.

Launch the interactive TUI

1$ databasecli
2# or explicitly:
3$ databasecli tui

List all stored database connections

$ databasecli list

Databases:
  production   localhost:5432/myapp      (admin)
  staging      staging.db:5432/myapp     (admin)
  development  localhost:5433/myapp_dev  (dev_user)

Check health of all databases

$ databasecli health

Health Check Results:
  production   OK      12ms
  staging      OK      45ms
  development  FAIL    connection refused

Configure your databases

1[production]
2host = localhost
3port = 5432
4user = admin
5password = secret123
6dbname = myapp
7
8[staging]
9host = staging.db
10port = 5432
11user = admin
12password = staging_pass
13dbname = myapp

See it in action

Real workflow from setup to health check.

$ databasecli list

Databases:
  production   localhost:5432/myapp      (admin)
  staging      staging.db:5432/myapp     (admin)
  development  localhost:5433/myapp_dev  (dev_user)

$ databasecli health

Health Check Results:
  production   OK      12ms
  staging      OK      45ms
  development  FAIL    connection refused

# Launch the TUI for interactive management
$ databasecli