Los servidores de bases de datos pueden trabajar juntos para permitir que un segundo servidor tome el control rápidamente si el servidor primario falla (alta disponibilidad), o para permitir que varias computadoras sirvan los mismos datos (balanceo de carga). Idealmente, los servidores de bases de datos deberían trabajar juntos de manera transparente. Los servidores web que sirven páginas web estáticas se pueden combinar con bastante facilidad simplemente balanceando la carga de las solicitudes web entre varias máquinas. De hecho, los servidores de bases de datos de solo lectura también se pueden combinar con relativa facilidad. Desafortunadamente, la mayoría de los servidores de bases de datos tienen una mezcla de solicitudes de lectura/escritura, y los servidores de lectura/escritura son mucho más difíciles de combinar. Esto se debe a que, aunque los datos de solo lectura deben colocarse en cada servidor solo una vez, una escritura en cualquier servidor debe propagarse a todos los servidores para que las futuras solicitudes de lectura a esos servidores devuelvan resultados consistentes.

Este problema de sincronización es la dificultad fundamental para que los servidores trabajen juntos. Debido a que no existe una única solución que elimine el impacto del problema de sincronización para todos los casos de uso, existen múltiples soluciones. Cada solución aborda este problema de una manera diferente y minimiza su impacto para una carga de trabajo específica.

Algunas soluciones abordan la sincronización permitiendo que solo un servidor modifique los datos. Los servidores que pueden modificar datos se denominan servidores de lectura/escritura, maestros (master) o primarios (primary). Los servidores que siguen los cambios en el primario se denominan servidores standby o secundarios (secondary). Un servidor standby al que no se pueden realizar conexiones hasta que sea promovido a servidor primario se denomina servidor warm standby (standby tibio), y uno que puede aceptar conexiones y servir consultas de solo lectura se denomina servidor hot standby (standby activo).

Algunas soluciones son síncronas, lo que significa que una transacción que modifica datos no se considera comprometida hasta que todos los servidores hayan confirmado la transacción. Esto garantiza que una conmutación por error (failover) no perderá ningún dato y que todos los servidores con balanceo de carga devolverán resultados consistentes sin importar a qué servidor se consulte. Por el contrario, las soluciones asíncronas permiten cierto retraso entre el momento de una confirmación (commit) y su propagación a los otros servidores, abriendo la posibilidad de que algunas transacciones se pierdan en el cambio a un servidor de respaldo, y que los servidores con balanceo de carga puedan devolver resultados ligeramente obsoletos. La comunicación asíncrona se utiliza cuando la síncrona sería demasiado lenta.

Las soluciones también se pueden categorizar por su granularidad. Algunas soluciones pueden tratar solo con un servidor de base de datos completo, mientras que otras permiten el control a nivel de tabla o de base de datos.

El rendimiento debe considerarse en cualquier elección. Por lo general, existe un compromiso entre la funcionalidad y el rendimiento. Por ejemplo, una solución completamente síncrona sobre una red lenta podría reducir el rendimiento a más de la mitad, mientras que una asíncrona podría tener un impacto mínimo en el rendimiento.

El resto de esta sección describe varias soluciones de conmutación por error, replicación y balanceo de carga.