Skip to main content

Read-Only Database Replicas

Context​

Bitwarden utilizes Azure SQL Hyperscale and its high-availability replica available as a read replica. This allows Bitwarden to double the max worker limit (along with compute, memory, and network throughput) without needing to scale up the primary database. The HA replica replicates the primary instance by mirroring the transaction log records.

Vision​

More read-only capabilities should be used in conjunction with read-only replicas, especially after stored procedures have been tuned and there are prominent performance bottlenecks relating to read-only queries.

Usage​

We currently use the read-only replica in two areas:

  1. Methods within the Dapper repositories with using (var connection = new SqlConnection(ReadOnlyConnectionString)) defined.
  2. Data engineering pipelines that require direct connection to the database.

Gotchas / Considerations​

  • CAP Theorem applies here. Microsoft does not guarantee data consistency and propagation latency could vary greatly. For business logic that need consistency, read-only replicas are not a viable solution.
  • Lack of observability -- currently there is limited visibility into query performance metrics as well as resource utilization on the replica itself.
  • Long-running queries on read-only replicas can cause blocking.
  • The HA replica is not a backup and should not be treated as such. If a destructive migration had been run on the primary instance it will be reflected on the HA replica. DR procedures will have to be carried out in this scenario and there will be data loss.