Ouvi dizer que o desempenho de bancos de dados relacionais não fragmentados como MySQL ou PostgreSQL "quebra" além de 10 TB.
Suspeito que limites, como tais, existam, já que não haveria Netezza, Greenplum ou Vertica, etc.
Não há uma resposta simples para sua pergunta, mas aqui estão algumas coisas em que pensar.
Primeiro, a escala não é a única coisa com que se preocupar. O que você faz com seus dados é. Se você possui 500 tabelas e 30 TB de dados e está executando 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 diminui um pouco porque está precisando bater no disco em tudo. Da mesma forma, se você tiver 50 TB de dados, mas tiver um conjunto de aproximadamente 100 GB de ocorrências comuns, poderá criar um servidor com RAM suficiente para manter essa parte do banco de dados em memória e ficar com o 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 sharding. (Edit: Sharding pode, de fato, piorar esse problema . )
Os principais problemas com os quais você se depara com grandes bancos de dados no MySQL e no PostgreSQL envolvem o fato de que nenhum deles suporta paralelismo intraquery. Em outras palavras, uma consulta é executada como um único bloco por um único encadeamento 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 são resgatados, pois separam o armazenamento da execução e podem fazer isso no nível do coordenador. Observe que o Postgres-XC e a Green Plum usam essencialmente sharding internamente, mas os coordenadores reforçam toda a consistência globalmente.
Com o paralelismo intraquery, você pode interromper a consulta, fazer com que diferentes canais de E / S de processadores / disco executem partes dela e relate partes do conjunto de resultados a serem montados e transmitidos de volta ao aplicativo. Novamente, isso geralmente é mais útil em cargas de processamento analítico do que em transações.
A segunda coisa é que alguns sistemas, como Vertica ou Greenplum, armazenam colunas de informações juntas. Isso dificulta o uso do sistema a partir 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ê tiver mais de 1 a 2 TB de tamanho, poderá se deparar com várias vantagens e desvantagens entre sistemas e cargas de trabalho. Novamente, isso é específico para bancos de dados, tamanho de conjuntos de trabalho, etc. No entanto, neste momento, você realmente precisa usar sistemas de floco de neve, ou seja, sistemas únicos e personalizados para sua carga de trabalho.
Naturalmente, isso 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 suporte a decisões e cargas de trabalho de 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 uma atenção cuidadosa aos fundamentos (incluindo índices, autovacuum, como eles funcionam no nível baixo, etc.) e recursos computacionais suficientes, eles são totalmente gerenciáveis (e eu acredito que seriam gerenciáveis dentro da faixa de 30 TB na página).
Edit2 : Depois de ir para 100 TB, o que funciona depende do seu conjunto de dados. Estou trabalhando em um agora que não será dimensionado para esse intervalo, pois atingirá o limite de 32 TB por tabela no PostgreSQL primeiro.