DEV Community: SN

[Boost]

SN — Sun, 21 Jun 2026 10:31:57 +0000

Jun 21

DBeast MCP

SN — Sun, 21 Jun 2026 10:31:45 +0000

SQL access gives AI the data. DBeast gives it the investigation.

SN — Sun, 14 Jun 2026 09:10:37 +0000

snss10 / DBeast

Expert-level PostgreSQL database analysis MCP server for AI assistants.

A PostgreSQL MCP server that gives AI assistants expert DBA capabilities.

Quick Start · Demo · Tools · Safety · Configuration · Docs

DBeast connects AI assistants such as Claude, Cursor, Windsurf, and VS Code Copilot to PostgreSQL through the Model Context Protocol. Instead of exposing one broad execute_sql escape hatch, DBeast provides 21 focused tools for schema discovery, safe query execution, impact analysis, performance review, security checks, maintenance reporting, replication monitoring, and data quality inspection.

Demo

Watch Claude use DBeast MCP tools to audit a PostgreSQL database, identify security and maintenance risks, and preview cleanup impact without executing destructive SQL.

Watch the demo on YouTube

How It Works

AI assistant  --MCP stdio-->  DBeast server  --asyncpg-->  PostgreSQL
Claude/Cursor                  Python local                 Local, RDS,
Windsurf/VS Code               subprocess                   Supabase, Neon

DBeast runs as a local stdio MCP server. Your IDE or desktop assistant starts it as a subprocess and passes database credentials…

View on GitHub

Preventing context bloat and agent loops in database MCP servers

SN — Sun, 07 Jun 2026 08:29:52 +0000

I've been running Cursor and Claude Code with MCP for a while now, and one thing became obvious pretty quickly:

Giving an agent a generic execute_sql tool is usually a terrible idea.

The first problem is context explosion. If an agent needs to understand a database, it often starts by pulling huge schema dumps, table definitions, or query results directly into the conversation. Context gets consumed incredibly fast.

The second problem is what I call the agent loop trap. The model writes a query, gets an error, rewrites it, gets another error, and continues indefinitely. If you're using paid models, this can become surprisingly expensive.

To explore a different approach, I spent the last few weeks building DBeast, an open-source MCP server for PostgreSQL focused on discovery, diagnostics, and safety rather than unrestricted SQL execution.

Instead of exposing a single powerful database tool, DBeast exposes 21 specialized tools.

A few design decisions that ended up working well:

1. Schema mapping instead of schema dumping

Rather than feeding entire DDL definitions into context, the server reads information_schema and system catalogs to generate compact structural representations.

The goal is to help the model understand:

table relationships
foreign keys
cardinality
dependency graphs

without flooding the context window.

In many cases, a compact graph representation is dramatically more useful than thousands of lines of SQL.

2. Safety enforced at the tool layer

I didn't want agents performing unrestricted writes.

Read-oriented tools automatically enforce result limits, and mutation attempts are intercepted before execution.

For potentially destructive operations, the server can return an impact assessment instead:

estimated rows affected
dependency information
potential blast radius

This gives the model enough information to reason about consequences without actually making changes.

3. Breaking self-correction loops

One thing I noticed is that agents often treat database errors as invitations to keep retrying forever.

When PostgreSQL returns certain classes of errors, DBeast wraps them into structured responses that encourage the agent to stop, reassess, or ask for clarification instead of endlessly burning tokens.

4. Keeping everything local

The server runs locally using AsyncIO and standard MCP stdio transport.

Connection pools remain isolated, and no database metadata leaves the machine unless the host application chooses to send it to the model.

The project is MIT licensed and still early.

I'm particularly interested in how others are handling:

schema discovery
permission scoping
context management
preventing runaway agent/tool loops
safe database mutations

For those building MCP servers around data systems, what approaches have worked well for you?

GitHub: https://github.com/snss10/DBeast

I built DBeast: a PostgreSQL MCP server that gives AI assistants DBA-level tools

SN — Tue, 02 Jun 2026 21:25:33 +0000

AI assistants can write SQL.

But writing SQL is only a small part of working with a real database.

Most database work is investigation:

What tables exist?
How are they related?
Why is this query slow?
Which indexes are unhealthy?
Is autovacuum keeping up?
Are there risky permissions?
Which columns may contain sensitive data?
What would happen if we changed or deleted this data?

That is what I built DBeast for.

DBeast is a PostgreSQL MCP server that gives AI assistants structured DBA-style tools for understanding, analyzing, and troubleshooting PostgreSQL databases.

GitHub: https://github.com/snss10/DBeast

Why I built it

A lot of AI database integrations start with a simple tool:

execute_sql(query)

That is useful, but it is also incomplete.

A good database assistant should not just run SQL.

It should help you reason about the database.

It should inspect schemas, explain query plans, identify maintenance issues, detect security risks, analyze data quality, and help you understand the impact of changes before you make them.

That is the idea behind DBeast.

What DBeast does

DBeast exposes 21 MCP tools for PostgreSQL across areas like:

Schema discovery
ERD generation
Safe SELECT query execution
Query analysis
Query optimization hints
Write-impact previews
Database health checks
Maintenance analysis
Index and vacuum insights
Security audits
Sensitive data detection
Data quality reports
Duplicate detection
Replication monitoring
PostgreSQL configuration review
Audit logging

Instead of giving the assistant one giant database tool, DBeast gives it focused tools that map to real DBA workflows.

The bigger idea

I do not want AI assistants to be just SQL autocomplete.

I want them to become useful database copilots.

With DBeast, you can ask things like:

Show me how the sales schema is structured and generate an ERD.

Investigate why this dashboard query is slow and suggest indexes.

Review the public schema for maintenance issues, security risks, and data quality problems.

Compare table bloat, dead tuples, and index health across all schemas.

Find columns that may contain sensitive customer data.

Check replication lag and tell me if anything looks unhealthy.

That is much more useful than just:

Run this SQL.

Safety still matters

DBeast is designed to be safe by default.

SELECT queries can run with automatic row limits.

But write operations like:

INSERT
UPDATE
DELETE
DROP
TRUNCATE

are not executed directly.

They are analyzed as impact previews.

So instead of blindly running a risky query, your assistant can tell you:

what tables may be affected
how many rows may change
whether related objects are involved
what the risk level looks like
what you should review first

The human stays in control.

How it works

DBeast runs as a local MCP server.

AI assistant  ->  DBeast MCP server  ->  PostgreSQL

Your assistant talks to DBeast through the Model Context Protocol. DBeast talks to PostgreSQL using asyncpg.

It works with:

Local PostgreSQL
Docker PostgreSQL
AWS RDS / Aurora
Supabase
Neon
Railway
Render
Fly.io
SSH tunnels
AWS Secrets Manager

Quick start

git clone https://github.com/snss10/DBeast.git
cd DBeast
pip install -e .

Example MCP config:

{
  "mcpServers": {
    "dbeast": {
      "type": "stdio",
      "command": "python",
      "args": ["/absolute/path/to/DBeast/src/server.py"],
      "env": {
        "DATABASE_URL": "postgresql://user:password@localhost:5432/mydb"
      }
    }
  }
}

Then ask your assistant about your database.

Who this is for

DBeast may be useful if you:

use PostgreSQL
use Cursor, Claude Desktop, Windsurf, or another MCP client
want AI help understanding a database
want query and performance analysis
want safer database workflows
want a local tool instead of a hosted database agent

What I’m looking for

This is an early release, and I would love feedback from:

PostgreSQL users
DBAs
backend engineers
MCP builders
people experimenting with AI developer tools

I’m especially interested in:

what database workflows you would want next
whether setup is clear
what safety checks would make this more trustworthy
which MCP clients you want first-class examples for

GitHub: https://github.com/snss10/DBeast