使用 Supabase 与 Retool 构建安全的多用户 CRM SaaS（面向英国中小企业）

Source: Dev.to

传统 CRM 对中小企业的真实问题

许多主流 CRM 存在以下问题：

• 围绕销售管道而非运营构建
• 非技术团队使用困难
• 功能过多，小团队不需要
• 在多个用户扩展时成本高昂

因此，尽管存在数据一致性、访问控制和可扩展性方面的风险，许多中小企业仍继续使用电子表格。

我的目标是构建一个以工作流为先的 CRM，使其：

• 集中运营数据
• 安全地支持多个内部用户
• 保持简洁且具成本效益

为什么我选择 Supabase 与 Retool

Supabase (PostgreSQL + Auth + RLS)

Supabase 提供托管的 PostgreSQL 数据库，内置身份验证和行级安全（RLS）。这使其非常适合需要在数据库层面强制数据保护的 SaaS 系统，而不仅仅在前端实现。

选择 Supabase 的关键原因

• 原生 PostgreSQL（强大的关系建模）
• 行级安全实现细粒度访问控制
• 简单的身份验证集成
• 能够良好地扩展到生产系统

Retool (前端与内部工具)

Retool 让我能够快速构建：

• 基于角色的仪表盘
• 为业务用户提供的内部工具
• 为非技术团队设计的友好界面

这种组合使我能够在不牺牲安全性的前提下快速推进。

高层架构

Users
   ↓
Retool (frontend dashboards & workflows)
   ↓
Supabase (Auth + RLS)
   ↓
PostgreSQL database

最重要的设计原则是安全规则位于数据库中，而不仅仅在 UI 中。

每客户一库的隔离

我没有采用共享多租户数据库，而是选择了 每客户一库 模式：

• 每个客户拥有独立的 Supabase 项目/数据库
• 大幅降低跨租户风险
• 简化访问控制和合规性问题

在每个客户的数据库中，用户访问仍通过与已认证用户关联的 RLS 策略严格控制。这种方式特别适合为中小企业提供强数据隔离需求的早期 SaaS 平台。

使用 RLS 实现安全的多用户访问

最关键的技术点之一是通过行级安全实现用户范围的访问控制。我们不再依赖前端逻辑，而是直接在 PostgreSQL 中强制访问规则。

-- Users can read their own orders
CREATE POLICY "Users can read their own orders"
ON public.orders
FOR SELECT
USING (user_id = auth.uid());

这确保了：

• 用户只能访问自己的记录
• 即使前端被绕过，数据仍受保护
• 安全性在所有工具和查询中保持一致

该模式对任何处理敏感业务数据的 SaaS 都至关重要。

设计实用的 CRM 数据模型

数据库模式围绕真实的运营工作流设计，而非通用的 CRM 概念。核心实体包括：

• 客户
• 订单
• 调度/日期
• 用户与角色

重点在于：

• 实体之间的清晰关系
• 避免数据重复
• 支持未来功能扩展

关系型设计使得维护数据完整性和随时间演进产品更加容易。

为真实业务构建的经验教训

• 简洁胜于功能，有助于中小企业采纳
• 安全必须是隐形且可靠的
• 业务所有者更在乎清晰度而非仪表盘
• 基于反馈的快速迭代是竞争优势

许多决策都是通过与业务所有者的直接对话得出，而非凭假设。

可扩展性与未来改进

系统的设计支持逐步扩展，通过：

• 添加新工作流模块
• 强化报告与分析
• 引入面向客户的门户
• 自动化重复的运营任务

由于核心架构是模块化的，这些改进可以在不重新设计系统的前提下实现。

最后感想

为中小企业构建安全的 SaaS 产品并不需要企业级的复杂性——但确实需要深思熟虑的架构和坚实的安全基础。

通过组合：

• PostgreSQL + RLS（Supabase）
• 快速前端工具（Retool）
• 工作流驱动的产品设计

我们可以交付真正提升小企业运营的生产级系统。该方法已帮助我交付了一个正在被英国企业采用的安全 CRM SaaS 平台，同样的模式也可以在众多面向中小企业的数字产品中复用。