Supabase：一个 Postgres 撑起整个内容后台
Supabase 是一个把 Postgres 数据库变成完整后端平台的开源项目，仓库在 GitHub 上已有 108,503 颗星。它的定位很直接：不用自己拼认证、文件存储、实时订阅和数据库，而是把这一整套收进一个界面，底层就是一份标准的 PostgreSQL。
对独立开发者来说，这句话的分量在于「你不必再学一套新东西」。数据库语法是你已经会的 SQL，部署好的服务能直接连 Postgres 客户端。这套组合在 2026 年前后基本成了「用一次就回不去」的标配——我们在白物集里正是拿它当整个内容管线的底座。
三个最惊艳的地方
Postgres 本体，不是魔改。 Supabase 没有发明一套私有的查询语法。你在数据库面板里写的表和本机 Postgres 里写的表完全一样，迁移心智成本为零。但它在这个本体上叠了几样能力：pgvector 做向量检索、全文检索、JSONB 存储、PostGIS 做空间数据。也就是说，一套 SQL 既能存文章，又能存 embedding，还能检索「相似内容」，不用再引入第二个数据库。
一个面板收走整块胶水。 独立开发者的后端通常会拧成三四个服务：认证用一套、文件对象存储用一套、实时推送再一套、定时任务又一套。Supabase 把这些全收进 Auth、Storage、Realtime 和 Edge Functions。白物集的「采集 → 知识卡片 → 出稿 → 展示」这条链，原本每一环都要自己起服务，现在只靠这张 Postgres 和它的面板就转起来了。
RLS 当 API 层用。 Row Level Security（行级安全）是这里最聪明的设计。前台可以直连数据库，把鉴权逻辑写进数据库层的 policy。一条规则就能拦住未授权的读写，比你想象中在每个接口手写权限检查要省事，也更难漏。对内容站这种「匿名可读、写需要密钥」的场景，几乎是白送的。
白物集实际怎么用它
白物集的内容管线落在这张 Postgres 上：写好的文章存进 articles 表，采集到的知识卡片存进 knowledge_cards 表，前端 Astro 侧在服务端渲染时按 id 拉出来拼成页面。数据层、原理层、应用层的每条记录都能用外键串起来，这一点在「内容越写越多、开始互相引用」之后尤其重要。
2026 年 8 月把反馈层做成闭环时，我们又把这套用到 article_performance 表上——记录每篇文章的阅读量、百度收录情况、知乎点赞、收藏、评论，以及微信、抖音分发的数据。每周复盘时直接从这张表拉周报。
这里有一个真实的坑值得单独说。阅读量的埋点曾长期停在 0。排查完发现根本不是没人看，而是那一次写入指向了一张不存在的表——article_views 表没建，同时客户端又没有检查写入结果。请求照样返回了 HTTP 200，前端就当成「成功落库」，其实是典型的假成功。修复只用两步：先把表建出来，再让写入看错误。从 2026 年 8 月 12 日起，阅读量才开始真实累积。这个教训后来被写进白物集的发布管线清单：任何写库调用都必须检查返回的 error，不能只看状态码。
适合什么场景，不适合什么场景
适合：中小团队和独立开发者快速搭 MVP 和内容后台；需要认证、数据库、文件存储「一次给齐」的场合；想用 SQL 而不是再自学一套 NoSQL 的项目；以及希望把权限收进数据库层、少写胶水鉴权代码的场景。
不适合：想精细化调优数据库、有专职 DBA、追求极致吞吐的大型无状态服务；团队已经重度绑定某云厂商原生组件，迁移成本高于收益的场合；以及对数据主权有强合规要求、又不想承担自托管运维成本的情况——自托管也是它的一大卖点，但那部分运维是要自己接手的。
快速上手
第一步，起一个本地实例或云端项目。 本地直接用 supabase start 拉一套容器；云端就去 dashboard 建一个项目，拿到 project URL 和 anon key（公开键，配合 RLS 用）。
第二步，在 SQL Editor 里建表。 用标准 Postgres 语法：
create table articles (
id bigint generated always as identity primary key,
title text not null,
content_md text,
content_html text,
category text,
tags text[],
published_at timestamptz default now()
);
第三步，开启行级安全。 内容站要的是「匿名可读、写入要密钥」，两条 policy 就够了：
alter table articles enable row level security;
create policy "public read" on articles
for select using (true);
create policy "ingest write" on articles
for insert with check (true);
第四步，后端写入并检查错误。 这里就是那个坑的正面示范：
const { error } = await supabase.from('article_performance').upsert(row);
if (error) console.error(error.message);
第五步，接上你的前端或服务端。 用 @supabase/supabase-js 或 supabase 的 Python 客户端，把 project URL 和 anon key 传进去，那个前面建好的 API 就通了。
整套下来，一个能存内容、能按权限读写、还能在面板里直接看到每篇数据的内容后台就转起来了。对内容型项目来说，这可能是把「攒一套后端服务」变成「建几张 Postgres 表」的那一步。