话虽如此,我会考虑采用单一数据库方法,原因如下：

>维护：当每个注册的“客户端”运行数据库时,您将很容易地达到对应用程序模式进行的任何更改或升级必须应用于每个单个数据库实例的情况.这将变得可笑,快速.
>便利：您可能需要分析和使用统计信息,或某种方式管理所有这些数据库.查询单个数据库对于尝试为所有数据库聚合相同的查询相当微不足道.这不是规模.
>可扩展性*：如2中所述,您将需要一种特殊的聚合方式来查询有关客户端和整个应用程序的信息.你的应用程序越大,查询越复杂.另一个问题是,如果一个客户端使用该应用程序比另一个客户端更多,那么您将被鼓励进行哪些优化？您的应用程式,较大的客户资料库或较小的客户？不要忘记任何您所做的更改必须复制到所有数据库.
>备份：您可以轻松地备份一个数据库,只需创建转储并将其存储在某个地方即可.获得一千个客户端,现在您必须运行1000个数据库转储,并将其命名得足够好,以便能够识别它们,如果一个数据库损坏.你甚至会知道这是否会发生这种情况？数据库错误将被本地化到特定的错误,而不是整个应用程序.
> UI：用户注册或被邀请使用您的应用,并且属于一个特定的客户端.您要将该用户帐户保存到客户端的数据库吗？如果是这样,请查看在用户想要更改密码时使用该数据的问题的可扩展性,或者您想要发送电子邮件.那么,你是否告诉用户让你知道他们在哪个数据库,以便找到它们？
>简化：您每个客户端都有一个数据库,只需要使用一个数据库.你如何将他们合并在一起,而不会显着破坏事情？如果您使用自动递增的ID,将会出现主键冲突;如果您决定重新生成键,书签网址将会中断;跨表的外键将不再指向正确的记录.您的数据完整性将下降到平底锅.

您提到“白标”服务,通过自定义子域提供他们的产品.我不知道这些工作如何,但子域只是DNS区域文件中的基本CNAME或A记录.添加这些的过程可以自动化,应用程序的设计和一些服务器配置可以处理将这些子域与正确的帐户和数据链接.他们只是网址,所以也许在后端,应用程序不区分：

http://client.example.com
http://example.com/client

总的来说,您可能会认为所有这些问题都是您可以并希望处理的问题.但是请注意,通过这样做,您可能会在脚下拍摄自己,您可以从制定精心设计的单个数据库模式和前瞻性的前端获得更多收益.

* @ xQbert提到可扩展性与多个数据库的真正好处.我修改了这个答案,以澄清我更关心其他方面.