我个人认为在大部分应用场景下，题主的想法在我们进行数据库设计时是可行的。但是如果你的应用场景中包含以下需求时，那么你可以优先考虑创建一个新的Database，而不是Schema。
- 如果你希望对一组数据表的文字编码/排序规则 的默认行为进行定制时，你应该考虑将这组数据表(以及响应的数据库对象)放入一个新建的Database中，而不是一个Schema中. 这是因为关于文字编码/排序规则等行为的默认规则是以Database为单位进行指定的通过
CREATE DATABASE ${数据库名} WITH ENCODING = ${文字编码名} LC_COLLATE = ${字符串排序顺序};)。如果是同一个Database下的不同Schema，那么在这些Schema中建立的数据表共享相同的规则。 - 如果你希望能够对一组数据库表(或Function等数据库对象)的并发数进行单独控制时，你应该考虑将这组数据库对象放入一个新建的Database，而不是一个Schema中。因为在PostgreSQL中，可以对单个Database的最大并发访问的会话数进行单独控制(通过
CREATE DATABASE ${数据库名} WITH CONNECTION LIMIT = ${最大并发数};).而Schema只是一个纯逻辑的层次，因此它不具备相应的控制粒度。
注1： CREATE DATABASE指定的CONNECTION LIMIT在使用中存在以下限制条件：
The CONNECTION LIMIT option is only enforced approximately;
if two new sessions start at about the same time when just one
connection "slot" remains for the database, it is possible that
both will fail. Also, the limit is not enforced against
superusers or background worker processes.
- 注2: CONNECTION LIMIT的定义值如果超过了对postgres实例定义的
max_connections（定义在postgresql.conf中）时则无意义 - 如果你希望对一组数据库表(或Function等数据库对象)的访问进行严格隔离，而不仅仅是通过SQL层面的PRIVILEDGE来控制。那么你应该考虑将这组数据库对象放入一个新建的Database，而不是一个Schema中。这是因为在PostgreSQL中，对于Access控制，除了SQL级别的权限控制之外，还可以在pg_hba.conf配置文件中进行会话级别的认证控制，基于这种方法，可以对话的以下要素进行高精度的访问控制：
- 会话来源(ip地址)
- 会话所使用的数据库用户
- 会话的连接目标的Database名
此外，由于会话的最小连接单位是一个Database(在大部分数据库实现中，一个会话的连接目标都是定位于 实例 + 实例中的某个Database). 因此，如果是把一组想要严格隔离的数据库对象定义于另一个Database中，级别对一个数据库角色通过GRANT文赋予了这些数据库对象的访问权限，如果使用这个角色发起的会话没有连接至那些数据库对象所在的Database，在这个会话周期内该角色仍然无法看到那些数据库对象。
综上所述， 由于Schema是一个纯逻辑层面的概念，类似于“命名空间”的概念，因此，确实可以按照题主的说法基于不同的Schema对业务所需的数据库对象进行SQL级别的权限归类。但是，如果数据库设计中对于数据库对象的集合除了基于SQL的权限分类外还有诸如以上的特殊需求时，则应当考虑将这些数据库对象定义在一个新的Database中。