第二个问题：您存储的是哪种数据？你听起来像需要一个列存储数据库,它适用于某种数据仓库项目.

第三个问题：如果你坚持使用Postgresql(这是一个很好的数据库)是当前的版本吗？较早的8.x之前版本的速度非常慢,但是从那时起,很多工作都进行了改进,你提到的一些问题 – 比如autovacuum – 现在可以通过“一劳永逸”的设置轻松解决.

*  Data growing with snowball effect

关于此的一些额外信息将是很好的.它为什么滚雪球？你可以将其标准化以减少存储吗？

* existing postgresql locks table etc for vaccuum tasks periodically

如果这是一个问题,我可以告诉你,你正在运行旧版本.较新的版本具有针对此的每表控件,您甚至可以完全关闭它.

* Archiving data is tideous currently

这里很难做出任何判断,因为没有多少工作要做.存档被转储到什么媒体？涉及多少持续的I / O？你在什么时间范围内经营？多少数据？它需要是一个“热”转储还是“冷”？

* 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

你在谈论集群服务器安排.

对我来说听起来如下：

>您使用的是RDBMS,其交易性质不适合您的应用程序.
>您的应用程序似乎需要一种主要读取的数据库样式.它听起来并不像你需要它具有事务完整性.
>您正在处理的数据量很可能未正常化,也没有尝试对其进行标准化.
>你手工做太多太多了,需要更多的自动化.
>您喜欢集群解决方案的想法,可能是“云样式”计算.

除此之外,这里没有足够的信息来确定什么是合适的.