Seus requisitos abstratos gritam "PostgreSQL" para mim. No entanto, acho que vale a pena ficar a par do que a burguesia está fazendo, então aqui está uma lista de várias coisas que você pode querer verificar.
Coisas grátis
- CouchDB - um dos primeiros bancos de dados NoSQL, poderoso sistema de consulta de mapeamento / redução, altamente distribuído e tolerante a falhas. Um dos melhores candidatos ao NoSQL.
- Hyperdex - tabela de hash distribuída muito nova, com recursos de pesquisa.
- Riak - tabela de hash distribuída digna de algum respeito.
Coisas grátis estranhas
- Metakit - mais um banco de dados incorporado como SQLite, mas não baseado em SQL, portanto, mais processual.
- FramerD - bem como um banco de dados clássico de "rede", muito centrado em ponteiros. Talvez morto?
- Magma - Smalltalk OODBMS. Legal, mas não bem documentado.
Material não livre
- AllegroGraph - banco de dados RDF (gráfico), suporta SPARQL. Lisp-flavored.
- Caché - um banco de dados relacional / OO híbrido, originalmente baseado em MUMPS (IIRC).
- Objetividade - Um dos últimos OODBs realmente grandes. Muito poderoso, impressionante e caro.
- VoltDB - Banco de dados relacional altamente escalonável. Suporta "a maioria" do SQL. Muito novo. Eu acho que eles também têm uma versão da comunidade.
Conclusão
Eu não usei nenhuma dessas coisas extensivamente. Eu brinquei um pouco com a maioria deles e sempre voltei ao PostgreSQL. Analisando seus requisitos, o único que o PostgreSQL não atende prontamente é a escalabilidade. Por outro lado, para meus propósitos, é muito mais fácil jogar US $ 4000 em hardware em uma única máquina de banco de dados dedicada do que jogar US $ 4000 em nós da nuvem ou máquinas de baixo custo nesse problema. E existem maneiras de obter escalabilidade com o PostgreSQL, como o EnterpriseDB .
É muito divertido brincar com essas coisas de lado, mas quando chega a hora de colocar dados valiosos e irreproduzíveis de produção em algo, vários atributos entediantes como confiabilidade, estabilidade e viabilidade a longo prazo acabam surgindo.
Experiência de pensamento para você
Considere isto. Imagine que você é Mark Zuckerberg e precisa desistir de sua base de código ou de seus dados. Você pode manter toda a sua equipe de desenvolvimento, mas precisa desistir de todo o seu código - todas as linhas, dizer até todas as memórias dos desenvolvedores de como tudo foi implementado -, mas você deve manter todas as suas contas de usuário e todos os seus usuários carregados dados e tudo isso, ou você pode desistir de todos os dados. Mantenha todas as estruturas, servidores e configuração, a instalação, mas perca todas as linhas em todas as tabelas e todos os bancos de dados.
Deveria ser óbvio que seria pior perder os dados. Por que todos os seus usuários regeneram todos esses dados? Pense em todos os dados de marketing perdidos, e é assim que o Facebook realmente ganha dinheiro. E há muitos empreendedores que aproveitam a oportunidade para fazer com que as pessoas usem seu clone do Facebook - agora todos os ex-usuários desprivilegiados do Facebook estariam por aí pensando em alternativas. Por outro lado, se eles perderem a base de código, poderão reconstruí-la, provavelmente até melhor do que é agora, mas poderão ter algo online em pouco tempo. Caramba - eles provavelmente poderiam compraro Facebook de outra pessoa clona a base de código e carrega-a com os dados reais, mas você não pode simplesmente copiar os dados deles. Se o Facebook ainda tiver os dados importantes de todos em seus servidores, o incentivo para sair é muito menor. Ainda ruim, mas muito menos. Surpreendentemente menos.
A ironia é que é muito mais fácil perder todos os seus dados em um acidente do que perder todo o seu código. Para a maioria das empresas de internet, porém, os dados são a empresa, é o seu bem mais valioso. E esse é um forte motivo para considerar o uso de um banco de dados relacional tradicional, testado pelo tempo, antiquado e pouco sexy.