dbTalk · PostgreSQL and MySQL · web and phone
dbTalk learns what normal looks like for each database, flags what drifts from it, and answers questions like “show drift for the last week” with a chart and the numbers behind it. When a statement regresses, it writes the fix as a script your DBA can test.
Load against the typical value for that hour of the day, flags as they were raised and resolved, and the statements that drifted, ranked by the extra time they cost, with their text. One click analyzes a statement and writes its fix script.
Hourly measurements per statement, compared with a 14-day median for the same hour of day. Regressions, new heavy statements, execution spikes, plan changes (with pg_stat_monitor) and database-wide drift, each NEW, ONGOING or RESOLVED.
monitor.py · exit 4 = alert“Load over the last 3 days”, “WAL since yesterday”, “what flags fired this week?”, or a statement id. Built-in rules or your approved model read the question; the chart and caption always come from the data.
shareable answer linksTime, buffer reads, disk reads, temp spill and WAL per statement, on every version from 12 to 17. Uses pg_stat_monitor, pg_wait_sampling, pg_qualstats and track_io_timing when they are there.
pg_monitor role onlyStatement digests with rows examined against rows returned, full scans and joins, on-disk temp tables and lock time. Explains a sample statement and reads index usage and waits when enabled.
SELECT on performance_schemaMissing indexes found in the plan, temp spills, disk-bound reads, rows examined per row returned, N+1 query patterns, planning and JIT overhead, and unstable run times.
Analyze button · analyze_statementCREATE INDEX CONCURRENTLY, ALTER TABLE … ALGORITHM=INPLACE, LOCK=NONE, per-role settings, invisible indexes before drops. Every line commented out, every step with its undo. Never runs by itself.
Cache hit ratio, dead rows and vacuum, never-analyzed tables, unused indexes, forced checkpoints, buffer pool misses, redo capacity, connection headroom, checked against this database’s own numbers.
database_fix.sqlThe connection test lists every statistic dbTalk reads as OK, missing or optional, with the exact command or my.cnf line to enable it. Managed-service settings are in the guide.
grants_postgres.sql · grants_mysql.sqlSeven read-only tools over MCP or REST with an OpenAPI description, input validation, literal redaction and an audit log of every call.
mcp_server.pyMeasure, compare, flag, explain, fix.
A read-only user and a schedule are all it needs. dbTalk installs nothing in the database, and the website and agent tools read the stored history; only the hourly monitor and the Analyze button connect, read-only.
Differences between hourly reads of pg_stat_statements or the performance_schema digest table, plus database-wide counters. Restarts and statistics resets detected.
Median and spread of each measure over 14 days, by hour of day, so the 9 AM batch peak is normal, not an alert.
Regressions, new heavy statements, spikes, plan changes and database-wide drift, sized by the extra time they cost.
Plain-English captions and answers computed from the measurements. A model, if you use one, only chooses what to show.
Statement and plan analysis of the worst regressions and a step-by-step test script with undo, for change control.
Read-only sessions with statement time limits, and the smallest grants each engine offers (pg_monitor; SELECT on performance_schema). TLS with certificate verification by default. Literals in SQL are redacted before anything reaches a model. Every question and tool call is written to an audit log. Hosted sign-in uses scrypt password hashing, lockouts, single-use reset links and encrypted database credentials.
Every answer shows how the question was understood and is computed from stored numbers, so a model cannot invent a figure. Answers are links: send one to whoever needs to see it.
dbTalk installs from the browser on iPhone, Android and desktops, with no app store. Turn on alerts and a new regression arrives as a notification that names the database, never the SQL or the numbers; tap it and the chart opens.
Add a database with the read-only user and dbTalk tests the connection and every statistic it reads before saving. Within a week it knows what normal looks like for each hour of the day.
Nothing to install. dbTalk connects to your database over TLS with a read-only user, from one fixed address you allow through the firewall or security group.
Works with the managed services’ own statistics: turn on pg_stat_statements or performance_schema in the parameter group or server flags; the guide lists each setting.
Register the tool server over MCP or OpenAPI. Every tool is read-only, validated, redacted and audited.
The website, questions and flagging are engine-independent; each engine needs only a collector.
Ask Bandlei for a guided pilot. All it takes is one read-only database user.