图3. 独立模式（Schema）

在这种数据模型下，当客户尝试第一次使用该SaaS系统时，系统在创建用户环境时会创建一整套默认的表结构，同时将其关联到该客户的独立模式。此时一般使用SQL CREATE命令来创建模式，同时授权一个用户帐号来访问该模式。举例来说，在SQL Server 2005 中可以使用如下命令：
CREATE SCHEMA ContosoSchema AUTHORIZATION Contoso
接下来，系统可以使用SchemaName.TableName来访问该客户的模式：
CREATE TABLE ContosoSchema.Resumes (EmployeeID int identity primary key, Resume nvarchar(MAX))
一旦模式创建完毕，它将成为该客户所属用户帐号访问的的默认模式
ALTER USER Contoso WITH DEFAULT_SCHEMA = ContosoSchema
一旦默认模式设置完毕，在使用该客户的用户帐号进行SQL语句操作时就不要再使用SchemaName.TableName 来指定特定的数据表，而是只需要指明表名即可。因此在系统代码内一句简单的SQL语句就可以应用于所有客户，而且每个客户仅访问到自己的模式内的数据:
SELECT * FROM Resumes
这种客户独立模式的方式相对比较容易被实现，而且从数据扩展性而言，这种解决方案和独立数据库一样，客户可以相对自由的对其中的数据结构进行新增和修改。一般在最初创建该客户的模式时，系统会预先创建一整套默认的数据结构，但在那之后，客户可以对其做个性化的修改来符合其实际业务需求
这种客户独立模式的方式在数据共享和隔离之间获得了一定的平衡，它既借由数据库共享使得一台服务器就可以支持更多的客户，又在物理上实现了一定程度的数据隔离以确保数据安全。
但这种解决方案的一个不利之处就是当系统出现异常情况需要将历史备份数据重新恢复的话，流程将变得相对复杂。因为如果每个客户拥有独立数据库的话，那么只需恢复该客户最近的数据库备份即可。但在独立模式的模式下，如果简单的恢复数据库备份，那就意味着数据库内所有客户的数据将一同被恢复，无论该客户是否数据受损或需要做数据恢复与否。因此，在独立模式下，如果系统管理员希望恢复某个特定客户的数据，需要将数据库的备份解压到某临时服务器空间内，然后选定特定客户的表数据将其覆盖到系统主数据库内，一般来说，这将是一项非常复杂且耗时的工作。
这种客户独立模式的方式比较适合应用在每个客户拥有比较少的表数量的情况下，比如每个客户只有100张表或更少。这种方式毫无疑问可以在每台服务器上支持比独立数据库方式更多的客户数量，减低了服务供应商的运营成本。因此一旦SaaS系统的潜在客户们不介意其数据与其它客户的数据物理上存放在同一数据库内，这将是SaaS系统开发商一种理想的选择。