
Supabase Studio Firebase Wrapper 指南用 Postgres FDW 直接读取 Firebase Auth 用户与 Firestore 数据【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase在 Supabase 生态中Firebase 是一个常见的外部数据源——很多团队既有存量的 Firebase 项目Auth 用户、Firestore 文档又希望在新应用中使用 Postgres。本篇围绕 Studio 集成页中的 Firebase Wrapper 概览文档overview.md展开讲清它的定位一个基于 Postgres 外部数据包装器Foreign Data WrapperFDW的集成让你在 Postgres 里直接查询 Firebase 数据。读完本文你将掌握Firebase Wrapper 支持的连接对象及其完整参数默认值、加密策略、对应的 SQL 创建方式、FDW 的安全边界以及它与 Firebase 第三方登录、Firestore 数据迁移这两个相邻功能的区别。Firebase Wrapper 是什么原始概览文档只有三句话但信息密度很高它给出了两个关键定义Firebase is an app development platform built around non-relational technologies. The Firebase Wrapper supports connecting to below objects. The Firebase Wrapper is a foreign data wrapper which allows you to read data from Firebase within your Postgres database.翻译过来即Firebase 是围绕非关系型技术构建的应用开发平台而 Firebase Wrapper 是一个外部数据包装器FDW让你可以在 Postgres 数据库内部读取 Firebase 的数据。FDW 是 Postgres 的核心能力把外部系统里的数据映射成本地外表foreign table用标准 SQL 查询但数据实际仍存放在远端。Supabase 将这一能力扩展成开放的 Wrappers 框架Firebase Wrapper 就是其中一员。按该框架的概念体系Remote Server你要访问的外部系统这里是某个 Firebase 项目。同一个数据库里可以创建多个 Remote Server 连接不同的 Firebase 项目Foreign table数据库中的一张表映射到 Remote Server 里的某份数据对应本文下面介绍的 Users 与 Firestore Collection 两类对象。外表查询时数据不落库始终从 Firebase 实时拉取ETL / QETL你可以用insert into ... select from 外表把 Firebase 数据导入本地表批量 ETL可配合pg_cron定时也可以直接把外表当普通表join你的业务表做实时查询QETL即按需查询。从源码结构看概览文档本身只是 Studio 的一个静态展示条目它由一个注册表按需加载overviews.ts 中firebase_wrapper键对应一条动态importloadIntegrationOverview(integrationId)在用户打开 Integrations 页面的 Firebase 条目时才返回这段 Markdown 原文。该文件顶部的注释还解释了为何必须写成字符串字面量导入——webpack/turbopack 与 Vite/Rolldown 对模板字符串动态导入的处理不一致动态写法会在 TanStack 构建中抛Failed to resolve module specifier。Studio 中 Firebase Wrapper 的参数定义概览文档说 supports connecting to below objects支持连接以下对象具体对象、参数、默认值并不在 Markdown 里而是定义在 Studio 的常量 Wrappers.constants.ts 中。该条目声明了完整的技术指纹字段值含义namefirebase_wrapper集成 id即 static-data 目录名handlerNamefirebase_fdw_handlerFDW 的 handler 函数名validatorNamefirebase_fdw_validatorFDW 的 validator 函数名extensionNameFirebaseFdw对应 Wrappers 框架的扩展名labelFirebase界面显示名descriptionBackend-as-a-Service with real-time database界面描述categories[devtools, auth]集成分类开发工具 / 认证Remote Server 的两个必填选项在 SQL 层面Remote Server 对应一个CREATE SERVER。Firebase Wrapper 的 server 级选项只有两个且都必填选项名标签是否加密存储说明project_idProject ID否Firebase 项目的 ID只允许字母、数字与连字符sa_key_idService Account Key是encrypted: true多行文本域服务账号密钥的完整 JSON用于以 Admin 权限访问该 Firebase 项目sa_key_id标记为加密存储意味着 Studio 只会在服务端加密保存该密钥不会明文回显。服务账号 JSON 需要在 Firebase 控制台的 Project Settings → Service Accounts 中生成Studio 的常量里把该入口标注为urlHelper指向 Firebase Admin SDK 的初始化文档。支持的对象一UsersFirebase Auth 用户常量中第一个表模板 label 为Users描述为 Shows your Firebase users即把 Firebase Auth 的用户列表映射为外表。列结构固定为四列列名类型说明uidtextFirebase 用户 IDemailtext用户邮箱created_attimestamp创建时间attrsjsonb其余字段自定义声明、手机号、头像等对应的表级options及其默认值选项默认值可否编辑说明objectauth/users否editable: false锁定的 Auth 用户端点base_urlhttps://identitytoolkit.googleapis.com/v1/projects可编辑Identity Toolkit API 前缀limit10000可编辑单次拉取行数上限支持的对象二Firestore Collection任意集合第二个表模板 label 为Firestore Collection描述为 Map to a Firestore collection即把 Firestore 中任意集合映射为外表。列结构同样四列列名类型说明nametext文档标识created_attimestamp创建时间updated_attimestamp更新时间attrsjsonb文档正文嵌套字段拍平到 jsonb表级options选项默认值 / 占位符可否编辑说明object占位符firestore/[collection_id]是必填firestore/前缀 集合 ID决定映射哪个集合base_urlhttps://firestore.googleapis.com/v1beta1/projects是必填Firestore Admin API 前缀limit10000是必填单次拉取行数上限两类对象的共同点值得注意文档正文都是jsonb兜底attrs列。这呼应了概览文档开头Firebase 是非关系型平台的判断——非结构化的文档字段被序列化进attrs需要时用 Postgres 的 JSON 操作符-、-、jsonb_path_exists等再行拆解。SQL 实战创建 server、外表并查询Wrappers 框架在平台侧预装了扩展实际使用时按标准 FDW 语法创建 server 与外表即可。以下 SQL 与上面常量中的字段名、默认值一一对应扩展名取自常量中的extensionName: FirebaseFdwSQL 中按 Postgres 扩展命名惯例写作firebase_fdw-- 1. 扩展Studio 常量中 extensionName 为 FirebaseFdw create extension if not exists firebase_fdw; -- 2. Remote Serverproject_id sa_key_id加密存储的服务账号 JSON create server if not exists firebase_server foreign data wrapper firebase_fdw options ( project_id my-firebase-project, sa_key_id service-account-key-json ); -- 3a. 外表Firebase Auth 用户object 固定为 auth/users create foreign table firebase.firebase_users ( uid text, email text, created_at timestamp, attrs jsonb ) server firebase_server options ( object auth/users, base_url https://identitytoolkit.googleapis.com/v1/projects, limit 10000 ); -- 3b. 外表某个 Firestore 集合object 为 firestore/[collection_id] create foreign table firebase.firestore_orders ( name text, created_at timestamp, updated_at timestamp, attrs jsonb ) server firebase_server options ( object firestore/orders, base_url https://firestore.googleapis.com/v1beta1/projects, limit 10000 );创建之后QETL 式的实时查询就是普通 SQL例如把 Firestore 里的订单与本地auth.users关联select auth.users.id as user_id, o.name as order_id, o.attrs - total as total from firebase.firestore_orders o join auth.users on auth.users.email o.attrs - email where o.attrs ? vip;也可以走批量 ETL把拉取结果固化成本地表配合 Wrappers 概览文档中介绍的pg_cron调度方式insert into public.firebase_users_snapshot (uid, email, created_at, attrs) select uid, email, created_at, attrs from firebase.firebase_users;安全边界FDW 没有行级安全FDW 外表不提供 Row Level Security这是 Wrappers 官方文档反复强调的安全红线见 Foreign Data Wrappers 概览的 Security 一节。落到 Firebase Wrapper 上应遵循三条规则私有 schema所有 Firebase 外表放在独立 schema如示例中的firebase中且该 schema不要加入 API 配置里的 Additional Schemas避免被 PostgREST 直接暴露按需开窗需要对外提供数据时在publicschema 建security definer函数在函数内对attrs等列做过滤后再返回收紧执行权限security definer函数默认anon也能调用必须revoke后只授权给目标角色。以 Firebase 用户为例-- public 侧开窗函数只暴露邮箱前缀匹配的脱敏字段 create function public.list_firebase_emails(prefix text) returns table (email text) language sql security definer set search_path as $$ select u.email from firebase.firebase_users u where u.email like prefix || % $$; -- 收回默认执行权只授权给已登录用户 revoke execute on function public.list_firebase_emails(prefix text) from public, anon; grant execute on function public.list_firebase_emails(prefix text) to authenticated;客户端即可通过supabase.rpc(list_firebase_emails, { prefix: acme. })访问而不直接接触外表。易混淆概念辨析数据 Wrapper ≠ 第三方登录 ≠ 数据迁移Firebase 与 Supabase 的交叉点有三个容易混淆这里用仓库中的实现代码做个区分Firebase Wrapper本文主题数据层集成用 FDW读取Firebase 数据属于 Integrations 页的 Wrappers 条目分类为devtools与authFirebase Auth 第三方登录认证层集成让 Firebase 签发的 ID Token 直接当作 Supabase 的 JWT 使用。对应实现是 CreateFirebaseAuthDialog.tsx表单校验firebaseProjectId后提交oidcIssuerUrl: https://securetoken.google.com/${projectId}即注册 Firebase 项目作为 OIDC issuer——它不拉取任何数据只是声明接受哪个项目的令牌Firestore 一次性迁移若目标是彻底搬走 Firestore 数据而非持续同步仓库中另有专门的迁移指南 Migrate from Firebase Firestore to Supabase使用社区的firebase-to-supabase工具链firestore2json.js collectionName [batchSize] [limit]导出集合为 JSONbatchSize 默认 1000json2supabase.js再按none/smallserial/serial/bigserial/uuid/firestore_id主键策略导入 Postgres并支持自定义 hook 把嵌套文档拆分成多张表。小结Firebase Wrapper 概览文档虽然只有三行但它钉死了这个集成的本质FDW。围绕这个本质从 Wrappers.constants.ts 的常量可以还原出完整的操作面——server 级project_id 加密的sa_key_id两个必填项两类可连接对象auth/users用户表与firestore/[collection_id]集合表以及base_url、limit默认 10000等表级选项。配合 FDW 无 RLS 的安全约束私有 schema security definer开窗函数Firebase Wrapper 就是一条用 SQL 把 Firebase 当成 Postgres 的邻居的完整链路实时 join 走 QETL周期性固化走批量 ETL彻底搬迁则转向迁移工具链。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考