O ZODB possui uma implementação modular que permite que a sua camada de armazenamento (storage) seja implementada seguindo a especificação de uma interface. Atualmente, existem 3 implementações principais para storage, cada uma delas com características específicas no que diz respeito a recursos para recuperação de paradas e falhas.

A principal implementação de storage para o ZODB é a FileStorage, mantida por Jeremy Hylton (que também é o principal desenvolvedor do ZODB). Além dela, existem ainda a DirectoryStorage[6] mantida por Toby Dickenson e a BDBStorage[7] mantida por Barry Warsaw (que utiliza o BerkeleyDB como base).

3.1. FileStorage

O FileStorage é projetado para ter portabilidade. Sua implementação utiliza um arquivo de log único para armazenar todos os objetos e transações. Novas revisões de objetos são armazenadas no final do log. Em memória é mantida uma lista de apontadores para a posição de cada objeto no storage.

O FileStorage suporta Undo e exige que seja feito "pack" do banco de dados periodicamente para excluir versões antigas de objetos e objetos não referenciados (considerando inclusive referências cíclicas). O FileStorage ainda supporta Versions e ZEO.

É a implementação de storage com maior performance. O FileStorage exige uma quantidade de 2 a 10% de memória em comparação ao tamanho do arquivo de log (pois com pouca memória, a performance é muito prejudicada).

O FileStorage não foi planejado para suportar falhas. Apesar de recuperar automaticamente o banco de dados em situações de falta de energia, truncando o arquivo na última transação completada e copiando o restante do arquivo para um "backup" (que permite inspeção futura), o FileStorage não está preparado para situações onde o meio de armazenamento não seja confiável.

O FileStorage não possibilita a replicação de dados e, em caso de crash do arquivo de log, disponibiliza apenas um ferramenta para remoção dos objetos corrompidos; algo que pode resultar em um arquivo de log inaceitável, exigindo que o backup do log seja restaurado integralmente.

No FileStorage o backup pode ser feito "a quente", ou seja, com o banco de dados sendo executado e mantendo a consistência das transações em execução.

3.2. DirectoryStorage

O DirectoryStorage utiliza arquivos e diretórios para armazenar as revisões dos objetos do ZODB. O DirectoryStorage utiliza um arquivo por objeto mais um arquivo por transação. Apesar da implementação simples, o DirectoryStorage foi projetado para ter tolerância a falhas e permitir a recuperação de desastres.

O fato de ser baseado em uma estrutura de diretórios permite que os dados sejam facilmente replicados (em vários discos ou em várias máquinas). A única exigência para um funcionamento seguro é que seja utilizado um filesystem robusto para armazenar a estrutura de diretórios. Esse filesystem não pode armazenar arquivos no /lost+found em caso de falhas e deve ter boa performance com arquivos pequenos. O filesystem recomendado pelo desenvolvedor é o reiserfs.

O DirectoryStorage suporta Undo (e também exige "pack" periódico) mas não suporta versões. É compatível com ZEO. Possui performance inferior ao BDBStorage, mas exige pouca memória para executar.

Além de replicação on-line, o DirectoryStorage também permite backup "a quente", prevendo inclusive situações como falta de energia durante o processo de backup, onde o backup nunca é deixado pela metade (princípio de atomicidade transacional do backup). Além disso, todos os registros possuem um checksum MD5.

3.3. BDBStorage

O BDBStorage usa a edição do BerkeleyDB mantida pela Sleepycat[9]. O BerkeleyDB é um banco de dados embarcado (embedded database) famoso por sua robusteza, performance e escalabilidade. É utilizado em soluções de missão crítica por grandes empresas como a Hitachi, HP, Sun, Amazon, NASDAQ, FujiXerox, Alcatel, British Telecom, Cisco, RSA Security, EMC, Veritas e Motorola.

O Berkeley DB pode ser usado em aplicações que necessitem de storages concorrentes de alta performance, na recuperação de pares de chaves e valores. O software é distribuido como uma biblioteca que pode ser compilada diretamente nas aplicações. Também pode ser acessado através de interfaces definidas para algumas liguagens como: C, C++, Java, Perl, Python e TCL. É importante saber que o Berkeley DB não é um servidor de banco de dados que manipula conexões de rede, não pode ser considerado como um SGBD relacional ou orientado a objetos e também não possui uma linguagem de consulta como o SQL.

O BerkeleyDB é distribuido em 6 versões diferentes[8], sendo que 2 delas são voltadas ao armazenamento nativo de XML. Dentre as versões convencionais, a versão "Berkeley DB High Availability" possui a totalidade de recursos e permitirá a criação de um storage ZODB com replicação, distribuição e balanceamento de carga.

O DBDStorage tem a grande vantagem de utilizar as ferramentas do BerkeleyDB para administração. Dessa forma, situações de parada ou falha podem ser recuperadas utilizando ferramentas reconhecidamente confiáveis.

O Berkeley DB suporta transações ACID, Undo e Redo (write-ahead logging), recuperação de falhas com checkpoints, utiliza bloqueio para o controle de concorrência (two-phase locking) e detecta deadlocks.

No BDBStorage, cerca de 20 tabelas são utilizadas para armazenar as estruturas do storage, o que inclui os objetos e contadores de referências.

O BDBStorage possui duas variantes, uma implementação mínima e uma completa. Na implementação completa, Undo e versões são suportadas. Na versão mínima esses recursos não estão disponiveis.

A performance do BDBStorage é um pouco inferior a do FileStorage. No entanto, o BerkeleyDB possibilita que a quantidade de memória de cache utilizada seja configurada de forma bastante flexivel.

Assim como no FileStorage, o BDBStorage requer que "packs" periódicos sejam feitos, suporta backup "a quente" e recupera-se automaticamente de falhas.