Answers:
您的问题没有简单的答案，但是这里有几点需要考虑。
首先，规模并不是唯一要担心的事情。您对数据所做的就是。如果您有500个表和30 TB的数据，并且您正在执行简单的OLTP，报告很少，那么我认为您不会有太多问题。PostgreSQL上有32TB数据库。但是，与此同时，性能将有所下降，因为它必须在所有设备上都命中磁盘。同样，如果您有50TB的if数据，但是通常有大约100GB的数据命中，那么您可以构建具有足够RAM的服务器以将那部分db保留在内存中，那么您就很聪明了。
另一方面，如果您尝试从1TB数据中提取该模式（最常用的值），则无论使用什么系统都无所谓，无论是否使用分片，这都会很痛苦。（编辑：分片实际上可能会使这个问题更严重。）
您将在MySQL和PostgreSQL上使用巨大的数据库遇到的主要问题涉及以下事实：它们都不支持查询内并行性。换句话说，查询由单个线程作为单个块运行，并且不能分解成多个部分并单独运行。当对大量数据运行大型分析查询时，这通常是一个问题。这是Postgres-XC和Green Plum进行救援的地方，因为它们将存储与执行分开，并且可以在协调员级别执行此操作。请注意，Postgres-XC和Green Plum本质上在内部使用分片，但是协调器在全局范围内强制执行所有一致性。
使用查询内并行性，您可以分解查询，让不同的处理器/磁盘I / O通道运行查询的一部分，并报告要组合的结果集的各个部分，然后传递回应用程序。同样，这通常对分析而不是事务处理负载最有帮助。
第二件事是某些系统（例如Vertica或Greenplum）将信息列存储在一起。从OLTP的角度来看，这使系统更难使用，并且降低了那里的性能，但是却大大提高了大型分析工作负载的性能。因此，这是特定于工作负载的折衷方案。
因此，答案是，一旦大小超过1-2 TB，您可能会发现自己在系统和工作负载之间面临许多折衷。同样，这是特定于数据库，工作集的大小等的。但是，在这一点上，您确实必须使用雪花系统，即那些针对您的工作负载而定制的系统。
当然，这意味着限制通常是不可量化的。
编辑：我现在使用9TB数据库，该数据库处理PostgreSQL中的决策支持和事务处理工作负载的混合。最大的挑战是，如果您有涉及数据集大部分的问题，则必须等待一段时间才能找到答案。
但是，在仔细注意基本原理（包括索引，自动清空，它们如何在低水平上工作等）和足够的计算资源之后，这些都是完全可管理的（我估计在Pg的30TB范围内可以很好地管理）。
Edit2：一旦达到100TB，什么方法有效取决于您的数据集。我现在正在开发一个不会扩展到该范围的文件，因为它将首先达到PostgreSQL中每个表的32TB限制。