What is database availability?
Database availability is the ability of an authorized workload to complete an intended database operation correctly and within an agreed time when that operation is expected to be served. A reachable port or running process is insufficient. The service can be unavailable because authentication fails, the writer is read-only, replicas are stale, pools are exhausted, storage is full, queries exceed the latency objective, or responses are incorrect.
Define availability from the workload contract: which endpoint, operation, data freshness, consistency, latency, region and maintenance window count. Then measure successful eligible events divided by total eligible events. Document exclusions narrowly so planned maintenance, client errors or dependencies do not become a way to erase real impact.
How to measure database availability with SLIs and SLOs
An SLI is the measured indicator; an SLO is the target over a defined window. Use request- or operation-based events when possible because they preserve the amount of demand affected. Time-based probes alone can miss partial failures and low-traffic impact.
| Signal | Useful definition | Blind spot |
|---|---|---|
| Successful operation ratio | Valid operations meeting correctness and latency divided by valid attempts. | Can misclassify client misuse or retry storms without eligibility rules. |
| Write availability | Authorized writes committed durably within objective. | A readable replica can hide writer failure. |
| Read availability | Reads return correct-enough, fresh-enough data within objective. | Success status can hide stale or incomplete results. |
| Connection availability | Fresh sessions complete DNS, TCP, TLS, authentication and selection. | Existing pools can keep working while new connections fail. |
| Synthetic availability | Controlled end-to-end checks from representative sources. | Probe identity, path or query may differ from users. |
Database uptime versus database availability
Uptime often describes whether infrastructure or a process is running. Availability describes whether the required service outcome is delivered. A database can have process uptime while every login fails, storage is read-only, a critical table is locked, replication is too stale, or latency exceeds the business deadline. Report infrastructure uptime as a supporting signal, not the user-visible objective.
How many nines of database availability are realistic?
Choose an SLO from business consequences, dependency capability, architecture, operational maturity and cost—not from a slogan. More nines require smaller failure domains, faster detection and recovery, safer changes, tested redundancy and lower dependency budgets. Allocate an error budget across the complete service because a database target alone cannot exceed the weakest critical dependency.
Design database availability across failure domains
Redundancy is useful only when failures are independent
Two replicas sharing the same host, storage, zone, network path, credential, certificate, DNS control plane or deployment mistake are not independent protection against that shared failure. Map physical and logical dependencies, including identity providers, secret stores, proxies, orchestration, backups and operators. Test one failure domain at a time and combined scenarios justified by risk.
Synchronous versus asynchronous replication and availability
Synchronous replication can improve durability and failover data currency but may reduce write availability when a required replica or network link is unavailable. Asynchronous replication can keep the writer serving while introducing lag and possible data loss at failover. Select modes using explicit RPO, RTO, consistency and latency requirements, then monitor the state that determines whether failover is safe.
Connection endpoints must follow database failover
A healthy new primary is not useful if clients retain an old IP, direct node hostname, stale DNS cache or long-lived connection. Use the documented service or cluster endpoint, define DNS and pool lifetimes, retry only safe operations, and validate writer/reader roles after failover. Avoid aggressive retries that amplify overload during recovery.
Database availability failure modes beyond a crashed server
Partial database availability failures
One tenant, schema, partition, shard, table, query class, region, identity or endpoint can fail while global probes remain green. Segment SLIs by critical workload dimensions and watch for error concentration, latency tails and data freshness. Avoid so many segments that no signal has enough traffic; use service architecture and impact to choose meaningful cuts.
Database is reachable but unavailable to the application
Reachability can coexist with TLS rejection, expired credentials, connection exhaustion, lock contention, storage pressure, read-only state, missing database mapping, incompatible driver behavior or queries that exceed deadlines. Build layered health evidence so a green port check does not suppress an application incident.
Capacity saturation becomes an availability event
CPU, memory, storage latency, transaction logs, IOPS, connection limits, worker queues, locks and replication backlogs can degrade until operations miss the latency objective or fail. Alert on user-impacting symptoms and leading saturation indicators. Capacity headroom should account for failover because surviving nodes must serve load after a failure.
Operate database availability with safe changes and observability
Database changes are a major availability risk
Schema migrations, parameter changes, upgrades, certificate and credential rotation, failover, maintenance, index work and application releases can change availability. Use prechecks, backups or rollback mechanisms appropriate to the change, canary scope, lock and duration estimates, compatibility tests, monitored execution and explicit abort criteria. A successful command is not proof that workloads remain available.
Availability monitoring needs client and server evidence
Server metrics explain resource and engine state; client telemetry shows DNS, network, TLS, authentication, pool, query and end-to-end impact. Correlate both with deployment, failover and dependency events. Protect sensitive query and identity data in telemetry, and preserve enough dimensions to distinguish environments, endpoints, operation classes and error stages.
Test database failover and recovery, not just backups
RTO and RPO for database availability
Recovery Time Objective defines the targeted restoration time; Recovery Point Objective defines acceptable data loss measured in time or business events. They are objectives, not observed results. Measure actual detection, decision, promotion or restore, endpoint convergence, application recovery, validation and backlog processing. Report the achieved recovery point and any uncertainty.
Why a successful database failover can still harm users
The engine may promote a replica while clients cache the old address, credentials are not valid on the new node, replication lag violates freshness, read/write roles are wrong, transactions are lost or retried unsafely, or capacity is insufficient. A recovery test must include representative clients, fresh and pooled sessions, business operations, correctness checks and dependency recovery.
Backups support recoverability, not continuous availability
Backups protect against deletion, corruption, compromise and some catastrophic failures, but restore time can be much longer than high-availability failover. Replication is not a backup because destructive changes and corruption can replicate. Use both according to risk, test restores to an isolated environment, verify data and application behavior, and protect backup credentials and retention.
A repeatable database availability incident workflow
Prioritize user impact and evidence. Avoid triggering failover or broad configuration changes until the failure domain and current data state are understood.
- Declare the affected service contractIdentify operation, endpoint, region, tenant or shard, latency/correctness objective and impact start.
- Separate total, partial and degraded failureCompare reads, writes, fresh connections, pooled sessions, replicas, critical queries and workload segments.
- Locate the failing layerCorrelate client DNS/TCP/TLS/auth/query evidence with server capacity, locks, storage, replication and change events.
- Choose the lowest-risk recoveryEvaluate retry, load shedding, rollback, traffic routing, failover or restore against data safety and dependency state.
- Validate business operationsTest fresh and pooled sessions, correctness, read/write roles, latency, replication, capacity and error rate.
- Close with measured recoveryRecord impact, SLI, detection, recovery stages, achieved RTO/RPO, backlog, residual risk and follow-up owner.
Prepare database availability evidence for compatibility review
Prepare sanitized engine, topology, endpoint roles, regions or zones, replication mode and lag, driver, TLS and authentication method, representative operation, latency objective, error stage, failover behavior, recovery target and recent changes. Do not include credentials or customer data.
Review database availability compatibility
Use the InfiniSynapse DB Compatibility Checker to organize endpoint, driver, topology and compatibility questions. Treat the output as diagnostic guidance, then validate the actual service with workload-level availability measurements and controlled recovery tests.
Open DB Compatibility CheckerDatabase availability FAQ
What is database availability?
Database availability is the ability of an authorized workload to complete an intended database operation correctly and within an agreed time when that operation is expected to be served.
How do you calculate database availability?
For an operation-based SLI, divide eligible successful operations meeting correctness and latency by all eligible operation attempts in the measurement window. Define exclusions and retries explicitly.
What is the difference between database uptime and availability?
Uptime usually describes running infrastructure or processes. Availability describes whether required user or workload outcomes are delivered correctly and on time.
Does replication guarantee database availability?
No. Replication adds redundancy but can share failure domains, lag, lose data at failover, lack capacity, or fail to converge endpoints and clients. Test the complete recovery path.
Why is a database reachable but unavailable?
TLS, authentication, database selection, permissions, connection limits, locks, storage, read-only state, replication freshness, query correctness or latency can fail after network reachability succeeds.
How should database failover be tested?
Use controlled failure scenarios and representative clients. Measure detection, promotion or restore, endpoint convergence, fresh and pooled sessions, read/write roles, correctness, latency, capacity, backlog, achieved RTO and RPO.