Production Readiness Checklist

This checklist applies to any engine. Each engine section has its own, with the specific commands and settings — start here, then work through the engine-specific one.

Every item is phrased so that it can be verified. "Configure security" is not a checklist item; "remote access for default administrative accounts is disabled and the check was performed from outside the network" is.

Checklist

0 of 45 complete

Topology and capacity

• Document the intended topology: node count, roles, availability zones, and which failures the design survives.
• Confirm at least one replica exists in a different failure domain from the primary.
• Record current utilisation of CPU, memory, disk, IOPS and connections, and the level at which each triggers an alert.
• Establish the growth rate of data volume and write throughput, and the date each resource is forecast to exhaust.
• Verify the storage layer can absorb peak write throughput plus background compaction, vacuum or merge work.

Backups and restore

• Define the recovery point objective and recovery time objective in writing, agreed with the service owner.
• Schedule backups at a frequency that satisfies the stated recovery point objective.
• Store backups outside the primary's failure domain — a different account, region or provider.
• Perform a full restore into an isolated environment and record the elapsed time.
• Verify restored data with row counts and at least one application-level invariant, not only exit status zero.
• Confirm backups are encrypted and that the decryption key is recoverable independently of the database.
• Set and test backup retention, including the deletion path for expired backups.

Replication and failover

• Decide synchronous or asynchronous replication per workload and document the data loss window each allows.
• Alert on replication lag with a threshold derived from the workload's tolerance for stale reads.
• Write the failover procedure, including how clients discover the new primary.
• Execute an unplanned failover in a production-like environment and time it.
• Confirm fencing prevents the demoted primary from accepting writes after promotion.
• Verify a promoted replica immediately gains its own replica and its own backup schedule.

Access control

• Disable or restrict remote access for default administrative accounts.
• Create one role per application with only the privileges that application uses.
• Remove default, sample and unused databases and accounts.
• Require TLS for client connections and for replication traffic.
• Restrict network access to specific source ranges; no database port is reachable from the public internet.
• Store credentials in a secret manager, and confirm no credential appears in code, images or environment dumps.
• Define the credential rotation procedure and the date of the next rotation.

Limits and timeouts

• Set an explicit maximum connection limit and confirm the sum of application pool sizes stays below it.
• Set a statement or query timeout for application roles.
• Set an idle-in-transaction timeout so an abandoned transaction cannot block maintenance indefinitely.
• Set memory limits per query or per connection where the engine supports them.
• Define what the application does when the connection pool is exhausted, and verify it fails fast rather than queueing without bound.

Observability

• Collect connection count, query latency, error rate, replication lag, cache hit ratio and disk usage.
• Enable the engine's slow query log or statistics extension and confirm data is arriving.
• Build one dashboard that answers 'is the database healthy' without further clicking.
• Alert on saturation of every resource that can reach 100%: disk, connections, memory, IOPS.
• Confirm every alert names an owner and links to a playbook.
• Set log retention long enough to investigate an incident discovered a week later.

Change management

• Apply all schema changes through a versioned, reviewed migration tool.
• Confirm each pending migration is safe to run while the application is serving traffic.
• Document the rollback path for the current release, including whether it is forward-only.
• Record the upgrade procedure for the next minor and major version of the engine.
• Subscribe to the engine's security advisories and define the patch window.

Documentation

• Name the on-call owner for this database.
• Write down how to connect for emergency access, and how that access is audited.
• List the applications that depend on this database and the impact if it is unavailable.
• Link the runbooks for the three most likely failures for this workload.