如题，目前有有需求希望能够给用户开放一个 SQL 数据库，开放 SQL 能力（ SaaS 场景需求），不然自己封装 SQL 难受，用户也难受。
小弟对 postgresql 之前只有使用经验，对其 user/database/权限能力了解不多，特来问问
chatgpt 推荐：一个 PG 实例，N 个用户，通过不同的 database 和 user 进行隔离，前面一个连接池保证一个 user 只能连接某个 database
我想问问这个方案：

安全性如何，能保证不同的用户之间无法看到彼此的数据，或者影响彼此的数据

多租户之前因为是共享一个实例，资源争抢的问题能解决么？

这个方案运维上有没有什么难点

开放的 user 会不会对实例本身有其他影响

小弟这块经验确实较少，而 chatgpt 我总感觉他有些方案不是很可信，特来问问，以及有哪家用这个场景在线上跑的吗？

用过 supabase 的免费套餐，还行

多个 schema 会比较好吧

你们是做底层 infra, 出租 database 么?
如果不是, 如果是做应用的, 那么答应这个需求的 PM/领导 应该被拖出去打一顿

下面这个是一般做法, 从易到难:
option-1. 开发个简单的 query API 给用户, 让用户发 HTTP GET 到 your/query/url?filter1=v1&filte2=v2&... 你们 API backend. 这样可以模拟出基础的 SQL 效果
option-2. 设计自己的 querying language, 可以是类 SQL, 也可是简化版 JS/Python, 然后发到你们 API backend, 解析后变成 backend query 逻辑返回给用户. 这样能达到更灵活的结果, 但是开发成本高.

像你们领导要求的，直接给个 SQL 数据库给用户... 属于不懂瞎指挥, 想象把开发该做的事情，甩给用户+运维. 可以想象这个项目后面有多痛苦. 让提这个需求的人，自己去擦屁股吧.

只要实现自动化部署，分库、分表、tenant_id 标记这三种方案都基本一样。

还是有合理场景存在的，比如 saas 服务，但是提供了报表平台这种，想让用户可以自己设计报表。我们公司的方案是分 schema 的。

你怎么地也得在外面套个 API 层，不然本来极其容易的开发工作，瞬间变成了(可能很复杂的)运维工作, 太折腾了

怎么说？ supabase 这么搞的？我登录上去可以新建 database 呀（我指 psql 链接过去 create database ）

隔离性是不是不太好，而且这本来就是类似 retool 一样的用户需要多表

是做类似 retool 的类似物，也就是每个用户本身就是创建多表的。现在倒腾了一堆 api ，用户自己也会 sql ，他难受我们也难受，不如搞成 database 方式提供呢，所以需求确实是提供 sql 能力。针对免费用户，混部，运维要求也不算高，但还是希望降低运维成本（谁知道免费用户会怎么用。。。

资源抢占呢？就是某些用户用的很暴力导致其他用户没得用的问题

就是类似的场景呀，现在包了半天接口，用户自己也会 sql ，他难受我们也难受

说多都是泪，用户不喜欢接受你的 api （要学习就不说了，而且数据方面的需求本身就很繁琐），sql 本身也不难学，用户表示还不如给一个 sql 口子，高阶用户也能用，我都准备写 sql parser 来搞这个需求了，想了想，搞了这么多还不如用 pg 提供的多租户方式，这样 bug 也少，主要问题就如你说的，运维成本是不是太高了，这部分很多就是免费用户，其实可以做严一些限制（但我对 pg 熟悉不高，不知道是不是可以像 docker 一样严格限制）

我们这就是 supperset 普通直连数据库只给 schema 的权限，页面嵌入到我们系统，客户用下来也没啥问题。

没什么难点，也可行，并且可以建一个实例池，超卖啥的都是基操了。唯一要注意的就是小心爆炸半径

想想都是运维地狱 @

superset 不是查询平台吗？可以加数据什么的吗？以及能保证用户无法看到其他人数据吗？

资源抢占已经是能预想到的事情了，主要还是怕会不会有 pg 什么小坑，有数据泄漏

主要想问问 pg 有没有什么小坑，最怕的是用户数据泄露

只读就行了，用户无法看到其他人数据这个问题由租户自己的报表开发人员来确保，我们只保证你们租户不能看到其他租户的数据就行。

直接上 docker 不就好了

这样混部会不会花费更多额外资源？

我想问的就是这么保证租户之间不能看到，pg 这块严格不严格，这块经验不多，特来请教

这就大可不必了，问问 AI 怎么配置权限，自己试试，除非是 pg bug （ pg 代码出了名的好）否则肯定泄露不了。