Servidores de banco de dados podem trabalhar juntos para permitir que um segundo servidor assuma rapidamente se o servidor primário falhar (alta disponibilidade), ou para permitir que vários computadores disponibilizem os mesmos dados (balanceamento de carga). Idealmente, os servidores de banco de dados deveriam trabalhar juntos sem problemas. Os servidores da Web que atendem páginas da Web estáticas podem ser combinados com bastante facilidade, simplesmente balanceando a carga das solicitações da Web para várias máquinas. Na verdade, os servidores de banco de dados de leitura-apenas também podem ser combinados com relativa facilidade. Infelizmente, a maioria dos servidores de banco de dados tem uma combinação de solicitações de leitura/escrita, e os servidores de leitura/escrita são muito mais difíceis de combinar. Isso ocorre porque, embora os dados de leitura-apenas precisem ser colocados em cada servidor apenas uma vez, uma escrita em qualquer servidor deve ser propagada para todos os servidores, para que futuras solicitações de leitura para esses servidores retornem resultados consistentes.

Esse problema de sincronização é a dificuldade fundamental para servidores de banco de dados trabalharem juntos. Como não existe uma solução única que elimine o impacto do problema de sincronização para todos os casos de uso, existem várias soluções. Cada solução aborda esse problema de uma maneira diferente, minimizando o impacto para uma carga de trabalho específica.

Algumas soluções lidam com a sincronização permitindo que apenas um servidor modifique os dados. Os servidores de banco de dados que podem modificar dados são chamados de servidores de leitura/escrita, mestre, ou primário. Os servidores de banco de dados que acompanham as alterações no servidor primário são chamados de servidores em-espera (standby), ou secundário. Um servidor em-espera que não aceite conexões até ser promovido a servidor primário, é chamado de servidor warm standby (passivo, em-espera), e aquele que pode aceitar conexões e permitir instruções de leitura-apenas é chamado de servidor hot-standby (ativo, em-espera).

Algumas soluções são síncronas, significando que uma transação de modificação de dados não é considerada efetivada até que todos os servidores tenham efetivado a transação. Isso garante que a comutação (failover) não perderá nenhum dado, e que todos os servidores com balanceamento de carga retornarão resultados consistentes, independentemente do servidor consultado. Em contraste, as soluções assíncronas permitem algum atraso entre o tempo de uma efetivação (commit), e sua propagação para os demais servidores, abrindo a possibilidade de que algumas transações possam ser perdidas na comutação por um servidor secundário (failover), e que os servidores com balanceamento de carga possam retornar resultados ligeiramente obsoletos. A comunicação assíncrona é usada quando a comunicação síncrona seria muito lenta.

As soluções também podem ser categorizadas por sua granularidade. Algumas soluções podem lidar apenas com todo o servidor de banco de dados, enquanto outras permitem o controle no nível de tabela, ou por banco de dados.

O desempenho deve ser considerado em qualquer escolha. Geralmente, há uma conexão entre funcionalidade e desempenho. Por exemplo, uma solução totalmente síncrona em uma rede lenta pode reduzir o desempenho em mais da metade, enquanto uma solução assíncrona pode ter um impacto mínimo no desempenho.

O restante dessa seção descreve várias soluções de redundância, replicação e balanceamento de carga.