A flight recorder for your databases, in your terminal.
A continuous, always-on session sampler for your database that runs in your terminal — and lets you scroll backwards in time when something breaks.
uvx dbpulse postgres://localhost/mydbDatabase performance monitoring either lives in heavy SaaS platforms ($70+/host/month, agents, infra) or in live-only terminal tools that forget everything the moment you close them. When an incident gets reported after the fact, there's no way to look back at exactly what the database was doing at 14:20.
DBPulse is agentless and read-only. It polls the database's own statistics views, renders a live dashboard, and continuously records session samples into a local SQLite file. One binary, one connection string, zero install on the target. When something breaks you scrub backwards in time to see the active queries, wait events, and query shapes that caused it.
Everything you need to understand a database under pressure
History is the moat. Every competing terminal tool shows you the database only in the present tense. DBPulse records, so you can replay. On top of that it leans into wait-event analysis and query fingerprinting — the techniques the entire commercial monitoring industry is actually built on.
Live session view
A dense, keyboard-first dashboard of active queries, QPS, and connection health — refreshed every second. htop, but for your database.
Backwards-in-time replay
Samples are recorded to a local SQLite file. When an incident is reported after the fact, scrub back to 14:20 and see exactly what the database was doing.
Wait-event analysis
Not just "what's slow" but "what is the database waiting on" — the diagnostic method the entire commercial monitoring industry is built on.
Query fingerprinting
Normalizes query shapes so you can rank by total time, not just the one slow query firing right now.
Agentless & read-only
Nothing to install on the target. One static command, one connection string, lightweight stat-view polling that never modifies data.
Agent-ready (MCP)
Exposes the collector as an MCP server so coding agents can ask "why is prod slow right now?" and get structured wait-event data back.
How it works
Point it at a database
Run one command with a connection string. No agent, no infrastructure, no config file to start.
Watch it live, record always
A live terminal dashboard renders instantly while every session sample is written to a local file in the background.
Scroll back when it breaks
Replay any moment with --since, break down wait events over time, and find the query shape that caused the incident.
Postgres today. The MySQL-compatible world next.
The Postgres terminal-tooling space is well served and actively maintained. The MySQL-compatible side (MySQL / MariaDB / SingleStore / TiDB) is served by two abandoned Perl scripts. Meanwhile the market is consolidating upward into expensive enterprise platforms (Metis acquired by Dynatrace, OtterTune shut down), leaving the self-hosted and mid-market segment thinner than ever. That gap is the opening.
Roadmap
Shipping the open-source tool first, then the hosted product on top.
PostgreSQL only. One screen: a live pg_stat_activity table plus a QPS sparkline. Connect via a URL arg or $DATABASE_URL — no config file yet. Published to PyPI, installable with `uvx dbpulse`. Tested against Docker Postgres under pgbench load. The goal is the smallest thing worth screenshotting.
Sample sessions every second into a local SQLite file. Add a time-scrubber and a `--since 14:00` replay mode. This is the moat — nothing else in the terminal-tooling layer records cleanly, so you can finally answer 'what was the database doing when the incident happened?'
A pg_stat_statements panel with normalized query shapes ranked by total time, plus a wait-event breakdown stacked over time. 'Which query shape burns the most total time' and 'what is the database waiting on' are the questions database engineers actually ask.
Add a MySQL adapter, then SingleStore (wire-compatible, extends MySQL). This is the under-served white space — the MySQL-compatible terminal world has no maintained tool. The adapter abstraction isn't proven until a second engine exists, so it comes after one engine is solid, not before.
A headless mode: `dbpulse export --prometheus` and JSON snapshots. This is the seam between a developer toy and real infrastructure, and the entry point to a hosted continuous-monitoring product.
Expose the recording collector as an MCP server so coding agents can ask 'why is prod slow right now?' and get structured wait-event and query data back. The adapters already exist by this point, so it's cheap to add and genuinely novel in this niche.
The 'terminal renaissance' (k9s, lazygit, btop) proved developers want dense, keyboard-first local tools. Python packaging finally ships cleanly via uv/uvx. And MCP has become the standard agent↔system interface — a recording collector is exactly the kind of structured source a coding agent can query to answer "why is prod slow right now?"
As a solo founder, Claude is my co-engineer across the whole stack: designing the database adapter abstraction, writing the async sampling collector, and reasoning about Postgres and MySQL internals so I can build diagnostics correctly instead of guessing. Startup credits let me move at the pace of a small team while I ship the open-source tool and the hosted product on top of it.
— Braeden Duong, Solo Founder, DBPulse
Open a terminal. Point it at your database.
DBPulse is open source and agentless. Install it with uvx and see your database the way a reliability engineer does.