// Database health check
Database health check for PostgreSQL, MySQL and MongoDB.
A fixed-scope review with a written report.
An OSSeva engineer reviews your PostgreSQL, MySQL or MongoDB clusters for configuration, performance, replication, backup and security problems, and checks every version against its end-of-life date. You get a ranked findings report and a readout call. The scope is agreed before we start.
Last reviewed
What does a Postgres, MySQL or MongoDB health check look at?
The same eight areas for every engine, with the engine-specific checks below. This is the fixed scope: it does not change per customer, which is why the price can be fixed.
| Area | PostgreSQL | MySQL | MongoDB |
|---|---|---|---|
| Version and support status | Running version and minor release against the community calendar | Running version against the MySQL LTS and innovation release calendar | Running version and patch release against the MongoDB release calendar |
| Configuration | Memory, connection, checkpoint, WAL and autovacuum settings against the workload | InnoDB buffer pool and redo log sizing, connection and temporary table settings | WiredTiger cache sizing, connection limits and read and write concern settings |
| Performance | Slowest and most frequent statements where pg_stat_statements is enabled, missing and unused indexes, bloat and dead tuple build-up | Slow query log or Performance Schema digests, missing and unused indexes, lock waits | Slow operations from the profiler, index usage and collection scans |
| Replication and failover | Streaming replication lag, replication slots, Patroni or repmgr configuration and failover behaviour | Replication lag and topology, GTID settings, failover design | Replica set membership, oplog window, election settings, shard balance if sharded |
| Backup and recovery | Backup method, retention, WAL archiving and whether point-in-time recovery has been tested | Backup method, retention, binary log retention and restore evidence | Backup method, retention and restore evidence |
| Security configuration | Roles and privileges, host-based access rules, TLS, installed extensions | Accounts and privileges, authentication plugins, TLS | Authentication, roles, TLS and network binding |
| Capacity | Disk growth, connection headroom, transaction ID age | Disk growth, connection headroom, replication backlog | Disk growth, connection headroom, index and working set size against memory |
| Monitoring and alerting gaps | What is alerted on today against what should be | What is alerted on today against what should be | What is alerted on today against what should be |
MariaDB, Redis and Valkey, Elasticsearch and ClickHouse are scoped case by case. OSSeva supports PostgreSQL first, then the other open source engines this site lists: MySQL, MariaDB, MongoDB, Redis and Valkey, Elasticsearch and ClickHouse. Every engine runs self-managed on your own servers, cloud account or Kubernetes. OSSeva does not support Microsoft SQL Server or Oracle Database, and it does not host databases.
What do I get at the end of a database health check?
A written report with these sections, and a call to go through it.
Summary
Overall position in plain language, the three findings that matter most, and what to do first.
Findings table
Every finding with its severity, the evidence we saw, and the recommended change. Sorted by risk.
End-of-life and patch exposure
Each cluster's version against its community end-of-life date, and the options if that date has passed or is close.
Prioritised remediation plan
What to change now, what to schedule, and what to leave alone, with the order we would do it in.
Readout call
A call with the engineer who wrote the report to walk through it and answer questions.
Sample findings table
Illustrative only. These rows show the format and the kind of finding. They do not come from a customer.
| Severity | Finding | Evidence | Recommendation |
|---|---|---|---|
| High | Autovacuum is not keeping up on the largest tables | Dead tuple counts and last autovacuum times on the biggest tables | Per-table autovacuum thresholds and a review of cost limits |
| High | Backups exist but no restore has been tested | Backup job history with no restore record | Schedule a restore test and a point-in-time recovery test, and record the result |
| Medium | Several indexes are never used | Index usage statistics since the last statistics reset | Drop after a review window to cut write cost and storage |
| Medium | Replica lag alerts are missing | Alert rules compared with the replication topology | Add lag and replication slot alerts with agreed thresholds |
| Info | Running version reaches community end of life within the planning horizon | Version compared with the vendor calendar | Agree an upgrade date, or cover the version with patched builds |
How does a database health check run?
The scope and the price are fixed up front. Timing is confirmed in the quote, because it depends on how many clusters are in scope.
Scope and quote
A short call to agree the clusters in scope and the engines involved. The scope and the quote are fixed before work starts.
Read-only access
We ask for read access to configuration and database statistics. The review does not need your application data.
Review
An engineer works through the scope matrix for each cluster, using your statistics and configuration, and writes up the findings.
Report and readout
You receive the written report and a readout call to walk through it. Fixing the findings is yours to do, or ours to quote.
Is my database version out of support? The end-of-life readiness angle
Every health check includes an end-of-life readiness assessment: each cluster's version against its community end-of-life date, and your options if the date has passed. Dates below were checked against endoflife.date on 14 October 2026. Each version has its own page with the detail.
| Version | Community end of life |
|---|---|
| PostgreSQL 13 | 13 November 2025 |
| PostgreSQL 14 | 12 November 2026 |
| PostgreSQL 15 | 11 November 2027 |
| MySQL 5.7 | 31 October 2023 |
| MySQL 8.0 | 30 April 2026 |
| MongoDB 6.0 | 31 July 2025 |
| MongoDB 7.0 | 31 August 2027 |
Full lists: PostgreSQL, MySQL and MongoDB end-of-life dates.
What happens after the report?
The report stands on its own and you can act on it yourself. If you want help, these are the usual next steps. None is required.
Upgrade or end-of-life plan
OSSeva Assure adds a written upgrade plan per engine, configuration and topology review, and audit evidence.
Patched builds for old versions
OSSeva Patch keeps versions past community end of life covered while you plan the move.
Ongoing DBA cover
OSSeva Operate takes monitoring, incident response, patching and upgrades on a remote DBA basis.
What about Kafka, RabbitMQ and Redis?
This health check is for databases. AceMQ publishes a Kafka health check, which is the place to start for messaging systems.
How much does a database health check cost?
The price is fixed once the scope is agreed. It depends on the number of clusters and the engines involved. Contact us for a quote.
Frequently asked questions
What is a database health check?
A database health check is a structured review of a running database for configuration problems, performance risks, backup and recovery gaps, replication weaknesses and version support status. It ends in a written report that ranks the findings and says what to fix first.
What does a PostgreSQL health check cover?
Version and minor release against the community calendar, configuration (memory, connections, checkpoints, WAL, autovacuum), slow statements and index use, bloat, replication and failover, backup and point-in-time recovery, roles and access rules, and capacity. The matrix on this page lists the checks for MySQL and MongoDB alongside it.
Does it include PostgreSQL performance tuning?
The review finds the tuning opportunities and recommends the changes, in the report. Making the changes is not part of the fixed scope: your team can apply them, or we can quote the work separately. OSSeva Operate includes VACUUM and analyze tuning for PostgreSQL on an ongoing basis.
What is a database end-of-life readiness assessment?
It is the part of the health check that compares each cluster's version with its community end-of-life date and lays out your options: upgrade, patched builds past end of life, or an ongoing service. The dates are on the OSSeva end-of-life pages.
Which engines can you check?
OSSeva supports PostgreSQL first, then the other open source engines this site lists: MySQL, MariaDB, MongoDB, Redis and Valkey, Elasticsearch and ClickHouse. Every engine runs self-managed on your own servers, cloud account or Kubernetes. OSSeva does not support Microsoft SQL Server or Oracle Database, and it does not host databases. The fixed-scope health check covers PostgreSQL, MySQL and MongoDB. Other engines are scoped case by case.
Do you do Kafka, RabbitMQ or Redis health checks?
Not on this page. This health check is for databases. AceMQ publishes a Kafka health check at acemq.com/kafka/health-check/.
How much does a database health check cost?
The price is fixed once the scope is agreed, and it depends on the number of clusters and the engines involved. Contact us for a quote.
Find out what is wrong before it pages you.
Tell us the engines and the number of clusters. We confirm the scope and send a fixed-scope quote.