SQL 与专有 NoSQL 比较
Aurabase 与 Google Firebase
Firestore 是具有隐式架构的专有 NoSQL 存储。 Aurabase 是具有本机行级安全性的关系型 Postgres 16。这一根本区别决定了本次比较中的其他一切。
火力基地 将您锁定在 Firestore 中，这是一个专有的 NoSQL 存储，没有本机连接，也没有专门的 EU/GDPR 主权立场。 光环基地 提供完整的关系 PostgreSQL 16 具有标准的行级安全性、可预测的基于资源的定价而不是按文档读取计量表，以及由一家法国公司在德国和芬兰运营的经过验证的生产基础设施。
特性比较
| 标准 | 光环基地 | 谷歌Firebase |
|---|---|---|
| Data Model | Relational PostgreSQL 16 · SQL joins, constraints, ACID transactions · embedded pgvector | Firestore document/collection NoSQL · no native joins · limited composite queries |
| Vendor Lock-in | Portable standard SQL · pg_dump/pg_restore export to any Postgres · MIT Rust workspace | Proprietary Firestore format · export limited to Google Cloud ecosystem |
| Row-Level Security | Postgres Row Level Security · standard SQL syntax, portable across migrations | Firestore Security Rules · proprietary rule language, non-portable |
| Server Functions | Deno/TypeScript (V8) and Rust binaries compiled to WASM, executed by a real Wasmtime runtime | Cloud Functions for Firebase — Node.js/Python runtime managed by Google |
| Billing Model | Resource-allocated pricing (RAM, CPU, GB) · no per-read/write operation meters | Per-operation billing (every document read/write/delete, Blaze plan) |
| Sovereignty & Jurisdiction | Verified production infrastructure in Germany and Finland (Hetzner) · French parent company | Owned by Google LLC (US corporation) · subject to CLOUD Act regardless of selected region |
| Realtime | Native Postgres CDC over NATS JetStream with server-side column filtering · WebSockets & SSE | Native Firestore realtime listeners (onSnapshot) |
| Native AI (NL2SQL, RAG) | NL2SQL and RAG built directly into backend · embedded pgvector · 3 native LLM providers (OpenAI, Anthropic, Gemini) | Vertex AI extensions on GCP · separate configuration and billing |
还评价Supabase？看看我们的 Aurabase 与 Supabase 比较.
关系力与 NoSQL 技术债务
Firestore 迫使开发人员进行广泛的数据非规范化。在两个集合之间添加关系意味着手动复制字段，从而存在每次更新不一致的风险。
外键、由查询规划器优化的多表连接、唯一性约束、标准 SQL 聚合以及用于 AI 的 pgvector 向量搜索。
没有简单的聚合查询，需要维护昂贵的复合索引。本机连接不存在：一切都必须在客户端重新组合。
数据可移植性 — Postgres 模式无缝导出 pg_dump 到任何 Postgres 服务器，无需中间转换。 Firestore 导出仍以专有格式锁定，该格式严格设计用于重新导入到 Firestore 或其他 Google Cloud 服务中。
Postgres 行级安全与 Firestore 安全规则
Firestore 依赖于专有的规则语言 - Firestore 安全规则 - 管理文档的读取和写入。 Aurabase 杠杆 PostgreSQL 行级安全性，直接在数据库引擎内部实现的行业 SQL 标准。
实际差异：RLS 策略是用 SQL 编写的（auth.uid(), 授权角色()），使用标准 SQL 查询进行测试，并且在任何 Postgres 环境中保持完全可移植。 Firestore 安全规则使用带有专有模拟器的定制语法，不可在 Firebase 外部转移。
服务器功能 - WASM 边缘功能与托管云功能
Cloud Functions for Firebase 在完全由 Google 管理的 Node.js 或 Python 运行时上运行。 Aurabase 提供两个运行时：Deno/TypeScript (V8)，接近 Firebase 体验，以及以 Rust 编译为 WebAssembly 的二进制文件，由真正的 Wasmtime 运行时执行 - 服务的生产依赖项，而不是内部测试。
身份验证 — Firebase Auth 与 15 个 OAuth 提供商 + 通用 OIDC
Firebase Auth 涵盖了基础知识 - 电子邮件/密码、魔术链接、大约十几个联合提供商（Google、Facebook、Apple、GitHub、Twitter、Microsoft、Yahoo、匿名访客） - 通过 Firebase 控制台进行管理。
Aurabase Auth 支持 15 个指定的 OAuth 提供商 - Apple、Bitbucket、Discord、Facebook、Figma、GitHub、Google、Kakao、Microsoft、Notion、Snapchat、Spotify、Twitch、Twitter 和 Zoom - 以及每个项目无限的通用 OIDC 提供商（约定） oidc:<名称>，适用于任何 OpenID Connect 发现提供商（例如 Okta）、TOTP MFA 和 Magic Links。
不再担心不可预测的 Firestore 账单
在 Firebase 上 火焰计划、云函数中的意外循环或分页不良的客户端查询可能会触发数百万次 Firestore 读取，并在数小时内累积巨额账单 - 每个文档的读取、写入和删除都是单独计量的。
- 资源分配计费：为配置的 CPU、RAM 和存储付费，而不是按行读取付费。
- 包含 Postgres 索引：在 Aurabase 上构建 B-Tree、GIN 或 HNSW 索引不会产生每次查询的增量费用。
- 透明配额：消费层在 Studio 中直接可见，每次操作计费意外为零。
完整的层级详细信息 Aurabase 定价页面.
主权和合规性——为什么 Firebase 不对此提出异议
Firebase 没有发布官方竞争对手比较页面，Google 也没有为 Firebase 维护专门的 GDPR/CLOUD Act 主权立场，这主要留给第三方比较。
生产基础设施由 Hetzner 在德国（纽伦堡、法尔肯施泰因）和芬兰（赫尔辛基）运营。运营公司 Aurabase SAS 是一家总部位于巴黎的法国公司。
Firebase 属于美国公司 Google LLC。选择欧洲 Firestore 区域不会改变母公司的管辖权 - 无论选择哪个区域，它仍然受美国云法案的约束。
何时继续使用 Firebase
在两种特定情况下，Firebase 仍然是一个可行的选择：一个团队深深嵌入 Google Cloud 生态系统，且现有的 GCP 集成需要完全重写；或者没有复杂关系实体模型的纯移动应用程序，其中文档/集合结构就足够了。
Firebase 的 Spark 免费套餐仍然是一种无需承诺即可轻松制作原型的方法。当架构变得复杂或 GDPR 合规性成为强制性合同要求而不是事后才考虑时，就会开始权衡。