首页

责任共担模型

运行数据库是您与Supabase共同的责任。有些事情我们可以为您处理，而有些事情则需要您自行负责。这是有意为之的设计：我们希望给予您自由使用数据库的权利。虽然我们_可以_设置更多限制来确保您不会出错，但这些限制最终可能会成为阻碍。

总结来说，您始终需要负责：

  • 您的Supabase账户
  • 访问管理（Supabase账户、数据库、表等）
  • 数据
  • 应用安全控制

通常，我们的目标是减轻您在基础设施管理和Postgres内部知识方面的负担，尽可能减少配置需求。以下是您需要了解的几点：

安全责任共担

我们为您提供数据库的完全访问权限。如果您将这一权限与他人共享（无论是团队成员还是公众），那么确保所提供访问级别得到正确管理就是您的责任。

如果团队中有经验不足的成员，您可能不应该给予他们生产环境的访问权限。您应当建立内部工作流程来明确他们能做和不能做的操作，通过限制访问来避免任何可能被视为危险的行为。

您还需负责确保包含敏感数据的表具有恰当的访问控制级别。同时，管理数据库密钥和API密钥、将其安全存储在加密存储中也是您的职责。

Supabase提供了数据安全防护措施，建议您始终启用行级安全(RLS)。

我们还会通过安全顾问向您发送安全警报，但实施相关建议是您的责任。

自主决定工作流程

使用Supabase的方式多种多样。

您可以选择使用我们的仪表盘、客户端库，或是Prisma和Drizzle等外部工具，也可以选用我们的CLI、Flyway、Sqitch等迁移工具，或是任何兼容Postgres的方案。在项目初期，您可以直接在数据库上开发，也可以从本地迁移到生产环境，或是使用多环境管理。

这些方式没有对错之分，取决于项目所处阶段。当项目进入生产阶段时，您绝对不应该直接在数据库上进行开发——但在原型设计阶段且没有用户时，这样做完全可行。

您需要对应用架构负责

Supabase 并非糟糕架构决策的万能解药。无论托管在何处，设计不良的数据库都会表现不佳。

通过增加计算资源，您可以暂时应付设计不良的数据库。但最终问题仍会显现。数据库模式设计是需要您投入最多精力的领域。这正是 Supabase 的优势所在——您可以将更多时间用于设计可扩展的数据库系统，而非纠结于实现 CRUD API 这类常规任务。

如果您不想在数据库内部实现业务逻辑，这完全没问题。您可以使用任何与 Postgres 兼容的工具。

您需要对第三方服务负责

Supabase 为灵活集成第三方服务提供了多种可能性，例如：

  • OAuth 和 SAML 登录提供商
  • SMTP 和 SMS 发送 API
  • 在 Postgres 函数或触发器中调用外部 API
  • 在边缘函数中调用外部 API

您可以自由使用和集成任何服务，但同时需要确保这些服务的性能、可用性和安全性符合您的应用需求。我们不会监控与第三方服务集成的中断或性能问题。根据具体实现方式，此类集成问题可能导致您的 Supabase 项目性能下降或服务中断。

如果您的应用架构依赖此类集成，您应当监控相关日志和指标以确保最佳性能。

根据您的熟悉程度选择Postgres使用方式

Supabase的目标是让Postgres的_所有_功能都易于使用。但这并不意味着您必须使用全部功能。如果您是Postgres老手，您可能会喜欢我们提供的工具。如果您从未使用过Postgres，可以从简单的功能开始逐步深入。如果您只想把Postgres当作简单的表格存储，这完全没问题。

您对自己的数据库拥有完全控制权

Supabase对您的数据库设置的限制很少。这给您带来了很大的控制权，但也意味着您可能会"破坏"某些东西。这里的"破坏"是广义的，指的是任何因数据库使用方式而影响应用程序运行的情况。

您需要负责采用最佳实践来优化和管理数据库：

  • 添加索引
  • 为大型查询添加过滤条件
  • 使用缓存策略
  • 优化数据库查询
  • 管理数据库连接

您需要负责配置足够的计算资源来运行应用程序所需的工作负载。Supabase仪表板提供了可观测性工具来帮助实现这一点。

进入生产环境前的准备

我们建议您查看并应用生产环境检查清单中提供的建议。该清单涵盖了本文讨论的责任事项，以及一些额外的生产环境准备最佳实践。

SOC 2与合规性

Supabase提供符合SOC 2标准的托管环境来管理敏感数据。我们建议您查看SOC 2合规责任文档以及上述生产环境检查清单。

医疗健康数据管理

您可以使用 Supabase 存储和处理受保护健康信息(PHI)。您需要承担以下责任：

有关HIPAA下的共同责任和规则的更多信息，请查阅HIPAA合规责任文档。