AI DBA on Bare Metal: Slow Log In, Diagnosis + Fix SQL Out (Data Never Leaves Your Network)

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

AI DBA on Bare Metal — a dead-simple CLI tool for MySQL DBAs. You feed it a slow query log (or a DBCheck inspection package), and an open-weight model running on your own hardware hands back three things:

1. Diagnosis — the root cause in 1–3 sentences, no fluff
2. Executable SQL — the actual ALTER TABLE, rewritten query, or parameter change that fixes it
3. Risk note — one line on what breaks if you run it blind

Who would pay for this? Any team running MySQL in production where the slow log is too sensitive for a cloud API. Slow logs leak your table names, your query patterns, your business logic. A managed "AI database advisor" means shipping all of that to someone else's servers — and paying per token forever. This runs on a box you already own, as often as you like, for the cost of electricity.

I'm a DBA. I built the thing I wished existed at 2 AM, when a slow query is melting production and I need a second pair of eyes that actually knows MySQL.

Demo

Run it:

$ python aidba.py --slowlog sample-slow.log

Output:

Parsed 3 slow queries, sending to model...
============================================================

SQL #1 — 12.35s

Diagnosis: Missing index on orders.created_at forces a full scan; the ORDER BY o.total then triggers a filesort over every row in the date range.

Fix:

CREATE INDEX idx_orders_created_total ON orders(created_at, total DESC);

Risk: Index build briefly locks the table on older MySQL versions; test on a replica first.

SQL #2 — 8.21s

Diagnosis: IN (SELECT ...) executes the subquery once per row in order_items — the classic correlated-subquery anti-pattern.

Fix:

SELECT COUNT(*)
FROM order_items oi
JOIN products p ON oi.product_id = p.id
WHERE p.category = 'electronics';

Risk: Verify that order_items(product_id) and products(category) indexes exist; add them if missing.

SQL #3 — 5.68s

Diagnosis: The query filters on both action and created_at, but at most one column is indexed — so it scans the table (or a single-column index) across the whole range.

Fix:

CREATE INDEX idx_user_logs_action_created ON user_logs(action, created_at);

Risk: Composite index adds write overhead and storage; negligible for a read-heavy table.

============================================================
[AI DBA] Diagnosis complete. Data never left your network.

The whole flow: parse the slow log → pick the top-N slowest queries → build a DBA-structured prompt → POST to a local vLLM → print the diagnosis. Under 100 lines of Python, zero third-party dependencies.

Video demo and full walkthrough coming — the model runs on my own dual-machine inference cluster, so the demo is a screen recording rather than a public URL. The entire point is that there is no public URL.

Code

https://github.com/aimdotsh/ai-dba

The repo is a single Python file on the standard library alone (urllib, re, json, argparse — no openai package, no frameworks):

• aidba.py — slow log parser + prompt builder + OpenAI-compatible API client
• sample-slow.log — try it with python aidba.py --slowlog sample-slow.log

It speaks to any OpenAI-compatible endpoint. I run it against vLLM serving DeepSeek-V4 on two machines (4×200G RoCE interconnect, >120 tokens/s), but any local model works — Ollama, llama.cpp server, whatever you have on your iron.

How I Built It

The stack is deliberately boring:

• Model: DeepSeek-V4 (open-weight), served via vLLM with its OpenAI-compatible /v1/chat/completions endpoint
• Client: ~100 lines of Python, stdlib only. No SDK — it's just an HTTP POST with JSON
• Prompt engineering: this is where the DBA knowledge lives. The system prompt enforces a strict output contract (diagnosis → executable SQL → risk note), temperature is 0.2 for determinism, and the parser pre-sorts the log by Query_time so the model spends its context on the queries that actually hurt

The key architectural decision: the model is infrastructure, not a service. No API key, no usage dashboard, no per-token billing. Point AIDBA_API_BASE at your own box and go. If your company already runs GPUs for anything, the marginal cost of one more DBA copilot is zero.

Why not just use a cloud API? Because the input is a slow log. Let me say that again: the input is your production query patterns. For anyone in finance, healthcare, or anyone with a sane security policy, "paste your slow log into a chatbot" is a non-starter. Local inference isn't a nice-to-have here — it is the product.

Why Does Open Innovation Matter?

Three reasons, and every one of them disappears the moment this is built on a closed API:

1. Data sovereignty is the feature. The selling point isn't "AI diagnoses your database" — cloud vendors already do that. It's "AI diagnoses your database without your data leaving the building." That sentence is only true with open-weight models you run yourself.
2. The cost structure makes the business work. A per-token DBA copilot gets most expensive exactly when you need it most — mid-incident, with a huge slow log. Self-hosted inference is a fixed cost. For a small team, that's the difference between "we can afford this" and "we'll just page the DBA."
3. Niche tuning beats general purpose. A generic cloud model gives generic advice. Because the weights are open, I can — and plan to — fine-tune on real DBA incident reports: MySQL-specific failure modes, version-specific gotchas, the stuff no general-purpose API will ever specialize in. Openness is what lets a one-person side hustle out-depth a vendor's ML team.

This also feeds my existing project: DBCheck, a free open-source database inspection platform. AI DBA consumes DBCheck's collection packages as input — the inspection finds what's wrong, the model explains why and how to fix it. Open weights make that pipeline possible without either side paying a toll to a third party.