第一个问题：如果你不需要ACID属性，为什么你要在关系数据库上开始呢？ 这听起来像是你在做一些非事务性的工作，所以用事务处理RDMBS可能对你的环境来说太重了。
第二个问题：你存储什么样的数据？ 你听起来像你需要一个列存储数据库，而且这是为某种数据仓库项目。
第三个问题：如果你坚持使用PostgreSQL（这是一个很好的数据库），它是当前版本吗？ 老版本的8.x版本出了名的速度很慢，但是自那时以来， 很多工作都进行了改进，现在您可以通过“一劳永逸”的设置轻松解决您提到的一些问题，比如autovacuum。
* Data growing with snowball effect 一些额外的信息，这将是很好的。 为什么它滚雪球？ 你可以规范化，以减less存储？
* existing postgresql locks table etc for vaccuum tasks periodically
如果这是一个问题，我可以告诉你，你正在运行一个旧版本。 较新的版本有这个表的控制，你甚至可以完全closures它。
* Archiving data is tideous currently
在这里很难作出任何判断，因为没有太多的工作要做。 什么媒体是被转储的档案？ 涉及多less持续的I / O？ 你在什么时间操作？ 多less数据？ 它是否需要成为一个“热门”垃圾场，还是会“冷”？
* Human interaction involved in existing archive, vaccuum, ... process periodically
我想看看“正常”使用如何需要人工干预，因为它不应该。 现在真空是自动的，并且（如前所述）可以被设置为根本不发生，并且大多数备份是脚本化的（并且当您可以脚本时，您可以安排）。 那么这是怎么发生的呢？
* Need a 'set it. forget it. just add another server when data grows more.' type of solution
你正在谈论一个集群服务器的安排。
这听起来像以下给我：
除此之外，这里没有足够的信息来弄清楚什么是合适的。
您也可以考虑查看HBase和HyperTable; 但正如艾弗里·佩恩（Avery Payne）提到的那样，您不会再给我们提供关于您当前应用程序的任何信息，只需要您的数据库平
有些事情要记住：
连接在非SQL平台上手动完成。 他们不会做外键，聚合等等。所有这些都是手动的。
现有的应用程序不一定很容易移植。 根据您要移植的代价，对于您纵向扩展PostgreSQL服务器（而不是水平）来说，可能更具成本效益。
你不会得到ACID，你必须手动pipe理并发。 根据您的应用程序，这可能是一个问题。 由于缺乏primefaces性，您也无法以传统的方式执行全球保护规则。
Cassandra是您知道需要扩展的最佳select。
我推荐一些来自http://wiki.apache.org/cassandra/ArticlesAndPresentations的案例研究文章
你能做些什么来解决你的一些问题是：
表没有locking，它只是执行缓慢。 这是通过postgresql来防止事务ID环绕。 您可以通过批量写入多行来降低频率，然后提交。 您可以使用队列（如rabbitmq）进行中间写入：application-> queue-> db。 这也会增加您的写入性能。
如果你的数据太大，几TB的订单，我会build议你搬到云端，因为倾销不是一个选项。 使用AWS或Google Cloud，并使用快照。 例如，速度非常快的EBS快照将在全球各地进行复制，并解决备份的需要。
如果通过归档，您的意思是删除数据并移动到“归档”，然后使用按date旋转的表空间。 这里有一些在线实现。