我的情况：我正在开发一个网络应用程序，当人们注册，我创建(实际上)一个数据库(不，它不是一个社交网络：每个人都必须访问自己的数据，从来没有看到其他用户的数据)。

这是我用于我的应用程序的上一个版本(仍然运行在MysqL上)的方式：通过plesk api，对于每个注册，我做：

>创建具有有限权限的数据库用户;
>创建一个只能由先前创建的用户和超级用户访问的数据库(用于维护)
>填充db

现在，我需要做同样的postgresql(项目越来越成熟，MysqL ..不能满足所有的需求)

我需要使所有的数据库/模式备份是独立的：pg_dump在两种方式下工作完美，对于可以配置为只访问1个模式或1个数据库的用户来说，这是完全相同的。

所以，假设你比我更经验的potsgres用户，你认为是什么是我的情况的最佳解决方案，为什么？

使用$ x db而不是$ x模式会有性能差异吗？
什么解决方案将更好地保持未来(可靠性)？

编辑：我几乎忘了：所有的数据库/模式将总是有相同的结构！

编辑2：对于备份问题(使用pg_dump)，也许更好的使用1 db和许多模式，一次转储所有模式：恢复将是相当简单的加载主转储在一个dev机器，然后转储和恢复只需要模式：有1个额外的步骤，但是倾销所有的模式看起来更快，然后逐个转储它们。

p.s：对不起，如果我忘了一些’W’字符在文本中，我的键盘遭受该按钮;

2012年更新

嗯，应用程序的结构和设计在过去两年里改变了很多dirung。
仍然使用1 db与许多模式方法，但仍然，我有1数据库为我的应用程序的每个版本：

Db myapp_01
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema
Db myapp_02
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema

对于备份，我定期转储每个数据库，然后在dev服务器上移动备份。

我也使用PITR / WAL备份，但正如我之前说，它不可能，我会一次恢复所有的数据库所以它可能会被驳回今年(在我的情况不是最好的方法)。

从现在起，即使应用程序结构完全改变，1-db-many-schema方法对我也很有效：

i almost forgot: all of my databases/schemas will always have the same structure!

…现在，每个模式都有自己的结构，改变对用户数据流的dinamycally反应。