Ouvi dizer que o desempenho do banco de dados relacional não fragmentado, como MySQL ou PostgreSQL, "quebra" além de 10 TB.
Suspeito que existam limites como tal, pois não se apresentaria Netezza, Greenplum ou Vertica, etc., no entanto, gostaria de perguntar se alguém aqui tem uma referência a algum artigo de pesquisa ou estudo de caso formal onde esses limites são quantificados.
Não há uma resposta simples para sua pergunta, mas aqui estão algumas coisas para pensar.
Primeiro, a escala não é a única coisa com que se preocupar. O que você faz com seus dados é. Se você tiver 500 tabelas 30 TB de dados e estiver fazendo OLTP simples com muito pouco relatório, acho que não terá muitos problemas. Existem bancos de dados de 32 TB no PostgreSQL por aí. No entanto, ao mesmo tempo, o desempenho será degradado um pouco porque é necessário atingir o disco em tudo. Da mesma forma, se você tiver 50 TB de dados, mas tiver um conjunto comum de cerca de 100 GB, poderá criar um servidor com RAM suficiente para manter essa parte do banco de dados na memória e você será de ouro.
Por outro lado, se você estiver tentando tirar o modo (valor mais comum) de 1 TB de dados, não importa qual sistema você esteja usando, isso será doloroso com ou sem fragmentação. (Edit: Sharding pode, de fato, piorar esse problema . )
Os principais problemas que você encontrará com bancos de dados enormes no MySQL e no PostgreSQL envolvem o fato de que nenhum deles suporta paralelismo intraconsulta. Em outras palavras, uma consulta é executada como um único bloco por um único thread e não pode ser dividida em partes e executada separadamente. Isso geralmente é um problema ao executar grandes consultas analíticas em grandes quantidades de dados. É aqui que o Postgres-XC e o Green Plum vêm em socorro, pois separam o armazenamento da execução e podem fazer isso no nível do coordenador. Observe que o Postgres-XC e o Green Plum usam essencialmente o sharding internamente, mas os coordenadores impõem toda a consistência globalmente.
Com o paralelismo intraconsulta, você pode dividir a consulta, fazer com que diferentes processadores/canais de E/S de disco executem partes dela e relatar partes do conjunto de resultados a serem montados e passados de volta para o aplicativo. Novamente, isso geralmente é mais útil em cargas de processamento analítico do que em transações.
A segunda coisa é que alguns sistemas, como o Vertica ou o Greenplum, armazenam colunas de informações juntas. Isso torna o sistema mais difícil de usar de uma perspectiva OLTP e diminui o desempenho, mas aumenta drasticamente o desempenho para grandes cargas de trabalho analíticas. Portanto, essa é uma compensação específica da carga de trabalho.
Portanto, a resposta é que, quando você atingir um tamanho acima de 1-2 TB, poderá se deparar com várias compensações entre sistemas e cargas de trabalho. Novamente, isso é específico para bancos de dados, tamanho de conjuntos de trabalho, etc. No entanto, neste ponto, você realmente precisa usar sistemas de floco de neve, ou seja, únicos e adaptados à sua carga de trabalho.
Isso, obviamente, significa que os limites geralmente não são quantificáveis.
Edit : Eu já trabalhei com um banco de dados de 9 TB que lida com uma mistura de cargas de trabalho de suporte à decisão e processamento transacional no PostgreSQL. O maior desafio é que, se você tiver perguntas que atingem grandes partes do conjunto de dados, terá que esperar um pouco pela resposta.
No entanto, com atenção cuidadosa aos fundamentos (incluindo índices, autovacuum, como eles funcionam no nível baixo, etc.)
Edit2 : Quando você chegar a 100 TB, o que funcionará dependerá do seu conjunto de dados. Estou trabalhando em um agora que não será dimensionado para esse intervalo porque atingirá primeiro o limite de 32 TB por tabela no PostgreSQL.