A pre-launch database health check catches replication lag, missing indexes, and backup failures before customers hit your app in production, not after. This guide walks through the exact sequence a database engineer runs 48 to 72 hours before go-live in 2026, plus the fixes when something fails mid-check.

TL;DR

• A pre-launch database health check needs backup-restore verification, index review, and replication lag checks completed 48 hours before go-live.
• Run EXPLAIN ANALYZE on your top 10 production queries before launch. skipping this is the top cause of day-one slowdowns.
• Load-test max_connections and pooling under simulated traffic; undersized pools crash first-day spikes fast.
• Compliance-heavy launches (fintech, payments) need an added audit pass beyond the standard checklist.
• If your team can't restore a backup in under 30 minutes during rehearsal, treat that as a launch blocker.

Make the launch decision before traffic arrives

A pre-launch database health check is a go/no-go gate, not a documentation exercise. In 2026, launch-day database incidents usually begin with one of three conditions that looked harmless in staging: an untested restore, a query plan that collapses at production volume, or a connection pool that fails at peak concurrency.

Use this decision matrix before approving go-live:

What you'll need

• A staging clone with production-representative data volume (not a 1,000-row sample)
• Slow query log enabled for at least 7 days before the check
• A recent backup file plus a scratch environment to test the restore
• Access to your monitoring dashboard (Percona Monitoring and Management, Datadog, or equivalent)
• pt-table-checksum or pt-online-schema-change if you're on MySQL or MariaDB
• A named rollback owner and an agreed maintenance window with stakeholders
• 4 to 6 hours of uninterrupted engineering time. this isn't a 30-minute task

The steps

1. Verify backup and restore end-to-end

A backup file you've never restored isn't a backup, it's a hope. Take your most recent full backup, spin up a scratch instance, and restore it completely. including point-in-time recovery if your setup supports it.

Time the restore. If it takes longer than your agreed recovery time objective, that's a launch blocker, not a footnote. Common mistake: testing the restore on a smaller dataset than production and assuming the timing scales linearly. it rarely does past a few hundred GB.

2. Audit indexes against real query patterns

Pull the slow query log and run EXPLAIN ANALYZE on your top 10 to 15 queries by frequency and by execution time. Look for full table scans, missing composite indexes, and queries doing filesort on large row sets.

Add or adjust indexes in staging first, then measure the query plan change before touching production. Common mistake: adding indexes based on schema review alone without checking actual query patterns. you end up with indexes nothing uses and missing ones for the queries that matter.

3. Check replication topology and lag

If you're running InnoDB Cluster, Group Replication, or a standard primary-replica setup, confirm every replica is caught up and GTID consistency holds across the topology. Simulate a write burst and watch lag under load, not at idle.

A replica lagging by seconds at idle can lag by minutes under real write volume. Common mistake: checking replication health once at idle and calling it done. lag under load is the number that matters on launch day.

4. Load-test connection limits and pooling

Simulate expected launch-day concurrent connections against your staging clone, then push 2x that number to see where it breaks. Check max_connections, your ProxySQL or PgBouncer pool sizing, and application-side connection timeouts.

Set the pool 20-30% above your projected peak, not at it. launch-day traffic estimates are almost always low. Common mistake: sizing pools off average traffic projections instead of peak-hour projections.

5. Review user privileges and security configuration

Confirm application users have least-privilege access, remove any default or test accounts still active from development, and verify SSL/TLS is enforced on all connections. For compliance-heavy launches. fintech, healthcare payments, anything touching cardholder data. give database auditing its own review; this MySQL 8.4 audit log filter guide shows how to capture security-relevant activity without logging every query.

Common mistake: leaving a developer's superuser account active in production because "we'll remove it after launch."

6. Confirm monitoring and alerting thresholds

Set alert thresholds for replication lag, connection count, disk I/O, and query latency before launch, not after the first incident. Test that alerts actually fire. send a test event and confirm someone's phone buzzes.

Common mistake: configuring dashboards without configuring alerts, so nobody notices the problem until customers report it.

7. Run a rollback rehearsal

Walk through your rollback plan on the staging clone as if it were a real incident: revert schema changes, restore the pre-launch snapshot, confirm application connectivity. Time it and document every step.

Common mistake: having a rollback plan written down but never rehearsed. the first live rollback attempt is the worst time to discover a missing step.

“If your team can't restore a backup in under 30 minutes during rehearsal, that's a launch blocker, not a nice-to-have.”

Troubleshooting

• Restore takes far longer than expected: check disk I/O throughput on the restore target and confirm you're not restoring over a network-mounted volume with limited bandwidth.
• New indexes slow down writes: you likely over-indexed a high-write table. drop indexes that don't map to a query in your slow log.
• Replication lag spikes under load and doesn't recover: check for long-running transactions on the primary blocking the replication thread, and confirm binlog format is ROW, not STATEMENT, for consistency.
• Connection pool exhausts under the 2x test: raise max_connections carefully (it costs memory per connection) and confirm your pooler's idle timeout isn't holding connections longer than needed.
• Alerts don't fire on the test event: check the alert integration token and confirm the monitoring agent has write access to the alerting service, not just read access to metrics.
• Rollback rehearsal reveals a schema migration with no down-migration: write the reverse migration before launch, not during an incident.

Tools and resources

• pt-table-checksum and pt-online-schema-change (Percona Toolkit) for MySQL/MariaDB schema and data checks
• EXPLAIN ANALYZE (native to MySQL, PostgreSQL, and MariaDB) for query plan review
• Percona Monitoring and Management or Datadog for replication lag and connection tracking
• ProxySQL or PgBouncer for connection pooling under load
• For regulated or high-availability workloads, include a performance and security audit alongside this checklist

What to do next

Run this checklist 48 to 72 hours before go-live, not the morning of. If the release includes a schema change, add the CI/CD migration preflight gate so lock exposure, replication behaviour, and recovery are reviewed before deployment.

FAQ

How long before launch should I run a database health check?

Run the full pre-launch database health check 48 to 72 hours before go-live in 2026. That leaves time to fix index or replication issues without rushing a change into production hours before customers arrive.

What's the single most important pre-launch check?

Backup restore verification is the most important check. an untested backup is not a real backup. Time the restore against your recovery time objective and treat any gap as a launch blocker.

How do I know if my connection pool is sized correctly?

Load-test at 2x your projected peak concurrent connections and watch for connection exhaustion errors. Size the pool 20-30% above projected peak since launch-day traffic estimates usually run low.

Do I need a different checklist for compliance-heavy launches?

Yes. fintech, healthcare payments, and other regulated launches need an added security and access-control audit pass on top of the standard checklist. Review privilege scoping and encryption-in-transit settings specifically for cardholder or personal data.

How much replication lag is acceptable before launch?

Acceptable lag depends on your application's read consistency requirements, but any lag that grows under simulated write load rather than staying flat signals a capacity problem. Test lag under a write burst, not at idle, before deciding it's acceptable.

What causes most launch-day database slowdowns?

Missing indexes on high-frequency queries and undersized connection pools cause most launch-day slowdowns. Both are catchable in a pre-launch check with EXPLAIN ANALYZE and a load test, days before real traffic arrives.

Should I rehearse the rollback plan or just document it?

Rehearse it on a staging clone, don't just document it. A rollback plan that's never been executed is the most common source of extended downtime when a real rollback becomes necessary.

Can I run this health check on a managed database service?

Yes. managed database providers typically run this checklist as part of onboarding before a workload goes live, plus ongoing monitoring after launch. The checks themselves (backup, indexes, replication, pooling) apply the same way whether the database is self-managed or managed.

The launch blocker teams miss

The restore-time test in step 1 catches more launch-week incidents than every other step combined. teams skip it because a backup file existing feels like enough, and it isn't until the recovery clock is running during a real outage that the gap shows up.

Related guides

• How to use EXPLAIN FORMAT=JSON for MySQL query optimization
• PostgreSQL WAL file retention and replication-slot monitoring
• PostgreSQL parameter tuning best practices

Get a pre-launch audit done

A second set of eyes on backups, indexes, and replication before go-live.