Prioritise the right customer
Start with connected Engines, estate health and active alerts, then move directly into the customer, server and workload that needs attention.
Give your support team one place to see which client database estate needs attention, investigate the cause and hand over evidence—not guesses.
Mini DBA brings monitoring, alerts, history, AI-assisted diagnostics and MCP access together across multiple customers and database platforms.
- Monitor SQL Server, PostgreSQL, MySQL, MariaDB, Oracle and Azure SQL.
- See active alerts and estate health across connected customer environments.
- Keep the historical metrics, queries and waits needed to reconstruct incidents.
- Help first-line and specialist engineers investigate from the same evidence.
Replace fragmented customer monitoring with one operational view
Support companies often inherit different database platforms, networks and support arrangements at every customer. Mini DBA creates a consistent investigation workflow without pretending those environments have the same connectivity or ownership.
Preserve evidence after the incident
Use retained metrics, queries, waits, deadlocks and alert history to understand intermittent problems after the live symptom has disappeared.
Make specialist knowledge reusable
Apply consistent alert policies and give support engineers guided AI investigation while keeping escalation grounded in the original monitoring evidence.
Flexible architecture for separate customer networks
Use one Engine for a normal reachable estate. In advanced deployments, place an additional Engine inside each customer, site or network boundary and connect those Engines to one browser Console.
Customer A
Mini DBA Engine
Database connections and collection
Customer B
Mini DBA Engine
Database connections and collection
Customer C or site
Mini DBA Engine
Optional additional boundary
Mini DBA Console
One operational view for the support team
Multiple Engines are optional and intended for advanced environments. Database credentials stay with the Engine that owns the monitoring connection; they do not need to be copied into an AI client.
Read the Multi-Engine deployment guide and organise servers with customer and site groups.
Database monitoring features for managed support
Standardise how the team detects, investigates, escalates and explains database problems across different service customers.
Cross-client alert triage
Review active alerts across connected Engines, then drill into the owning customer environment without losing context.
Customer and site grouping
Use clear Engine names and server groups to make customer, site, environment and ownership visible during triage.
Repeatable alert baselines
Copy, export and import tested alert configurations across compatible servers and connected Engines.
Historical investigation
Reconstruct slowdowns and recurring incidents from metrics, queries, waits, deadlocks and alerts collected before the ticket arrived.
Reports and service reviews
Turn retained database evidence into reports that support technical reviews, capacity conversations and customer follow-up.
Mixed-platform coverage
Use one operational workflow across Microsoft, open-source and Oracle database platforms instead of maintaining a separate tool for each customer stack.
Help support engineers move from symptom to evidence
The AI Assistant can use optional context from the page being investigated to explain performance symptoms, alerts, deadlocks and execution plans. Engineers choose the evidence included with the question and verify the answer against the Console.
The Mini DBA Database MCP Server gives approved compatible AI clients a broader route into monitoring evidence. Ask questions across the connected estate, identify the affected customer or server, then drill into the relevant platform and time range.
- Which customer systems need attention now?
- What changed before this database slowdown?
- Which alerts or blocking patterns keep recurring?
- Which systems show growing capacity or workload risk?
Clear operational and data boundaries
Customer separation begins with deliberate deployment and access choices, not a vague multi-tenant claim.
Engine ownership
Each monitored server belongs to the Engine that collects its data, owns its alert configuration and maintains its retained monitoring history.
Console access
Provide authenticated HTTPS access to the Console and expose only the networks, Engines and operational interfaces required by your support model.
AI and MCP controls
AI context is optional. Restrict MCP endpoint reachability, issue dedicated API keys and treat server names, database names, query text and operational history according to customer policy.
Database monitoring for MSPs FAQ
Can one Console monitor several customers?
Yes. Connect the Console to the Engines used by the customer environments, then use estate-wide views for prioritisation and Engine-owned views for detailed investigation.
Does every customer need a separate Engine?
No. Separate Engines are optional for advanced deployments where customer, site or network connectivity makes a distributed arrangement useful.
Which databases are supported?
Mini DBA monitors SQL Server, PostgreSQL, MySQL, MariaDB, Oracle and Azure SQL from the same Console.
Can alert policies be reused?
Yes. Tested alert configuration can be copied between compatible monitored servers and moved between connected Engines using export and import.
Can AI inspect all customer databases?
Only the evidence reachable through the configured workflow. In-page AI uses context selected by the user; MCP clients require endpoint access and an API key. Database credentials are not handed to the AI client.
Is MSP and white-label pricing available?
Contact Mini DBA to discuss the number of monitored database connections, customer environments and any branding or support requirements.
See how Mini DBA fits your managed database service
Explore a populated Console, install Mini DBA, or discuss an MSP deployment and pricing requirement.