開放數據標準：Postgres，OTel，與Iceberg，你知道哪個？
數據世界正在浮出水面的三大新標準：Postgres、Open Telemetry，以及 Iceberg。
Postgres[1] 基本已經是事實標準；OTel[2] 和 Iceberg[3] 尚在成長， 但它們具備當年讓 Postgres 走紅的同樣配方。常有人問我：“為什么最后是 Postgres 贏了？” 標準答案是“可擴展性” —— 對，但不完整。
除了產品本身優秀，Postgres 還踩中了開源生態爆點 —— 關鍵在于“開源的姿勢”本身。
開源的三個信條
我逐漸悟到，開發者判斷一個項目“開源味”濃不濃，大致看三點：
1.許可證：是否為 OSI 核準[4] 的開源協議。2.自托管：能否把完整產品端到端地自己部署。3.商業化：有沒有商業中立、無廠商綁架；更妙的是，有 多家 公司背書而非一家獨大。
第三點我領悟得最慢 —— 是的，Postgres 贏在產品力，但更贏在 “誰也控不住” 。 治理結構與社區文化決定了它不可能被任何公司收編。它就像國際空間站，多家公司只能合作，因為誰都沒本事說 “這就是我的”。
Postgres 點滿了 “開源” 技能點，但它也并非在所有數據場景里都是銀彈。
三類數據角色
數據領域里主要有三種 “操盤手” 及其趁手工具：
1.OLTP 數據庫：開發者 寫應用用。2.遙測 / 觀測：SRE 運維基建、調優應用用。3.OLAP / 數倉：數據工程師 / 科學家 挖掘洞見用。
數據生命周期通常是 1 → 2 → 3：先有應用，再加點基礎遙測（很多時候直接塞進 OLTP 系統），等表長到塞不下，就得上數倉了。
三類角色各玩各的，但行業正整體“左移”：工具越發友好，觀測與數倉也慢慢被開發者收編。SRE 和數據崗并非故意讓賢，只是數據庫本身越來越能打，創業團隊能撐更久再招專家。
三大開放數據標準
圍繞以上三大場景，正冒出三套滿足同樣開源三信條的開放標準：
1.OLTP： PostgreSQL2.遙測： Open Telemetry3.OLAP： Iceberg
后兩者更像“標準”而非“工具”，類似 HTML 與瀏覽器：大家約好格式，其他工具要么跟進要么淘汰。
圖片
標準往往草根起家，商業公司則陷入經典的 顛覆式創新[5] 兩難：
?不跟？潮流跑了，錯過增長趨勢。?跟了？自家產品鎖定度變低。
對開發者而言，這簡直不能更香了 —— 我們堅信[6]：可遷移性會逼著廠商拼體驗。
下面逐一展開深入探討。
Postgres：開放式 OLTP 標準
Postgres 雖是一款數據庫，卻已成 “標準接口”。 幾乎所有新數據庫都宣稱“兼容 Postgres wire 協議[7]”。 因為誰也管不了 Postgres，各大云廠商要么主動，要么被用戶倒逼著上架 Postgres —— 連 Oracle Cloud 都供著。 體驗差？一句 pg_dump 走人。Postgres 用 PostgreSQL License[8] —— 功能上和 MIT 相當。
OTel：開放式遙測標準
“open telemetry” 的名字是字面含義：開放遙測。OTel[9] 仍年輕且頗為復雜[10]，但契合開源三信條：Apache 2.0，廠商中立。 正如云廠商擁抱 Postgres，主流觀測平臺也在集體投 OTel，包括 Datadog[11]、Honeycomb[12]、Grafana Labs[13] 與 Elastic[14]。 想自托管？可選 SigNoz[15]、OpenObserve[16]，再不濟用官方 OTel 工具集[17]。
Iceberg：開放式 OLAP 標準
開放表格式[18] 算是新賽道：大家約定目錄+元數據格式，任何計算引擎都能查詢。 雖有 DeltaLake[19]、Hudi[20] 等對手，但目前 Iceberg[21] 已然領跑。
各大數倉陸續“投靠” Iceberg：包括 Databricks[22]、Snowflake[23] 和 ClickHouse[24]。 最關鍵的商業推手是 AWS —— 2024 年底官宣 S3 Tables[25]，在 S3 上提供開箱即用的 Iceberg。
S3：終極數據基礎設施
對象存儲很便宜，已成三大標準的基石。今天凡是數據工具，不是原生 S3 就是兼容 S3。
AWS S3 團隊連環上新，把 “S3 當數據庫” 的幻想推向現實。諸如 Conditional Writes[26] 和 S3 Express[27] —— 速度比普通 S3 快 10 倍，最近還 逆天降價 85%[28]。
圖片
不同場景對 S3 的姿勢略有差異：
?OLTP：性能要命，S3 與 NVMe 永遠隔著物理網線。因此重點是 Zero ETL & 分層存儲：冷熱數據自由搬遷。Postgres 現有多種讀 Iceberg 的方式，如 pg_mooncake[29]、pg_duckdb[30] 及 Iceberg FDW[31]。?遙測 / 數倉：關鍵字是“基數”。S3 越便宜，大家越把海量數據往里倒，催生“存算分離”的架構。于是出現一堆以計算層自居的嵌入式數據庫：如 DuckDB[32]（OLAP）、SQLite 的云后端存儲[33]、turbopuffer[34]（向量）、SlateDB[35]（KV）、Tonbo[36]（Arrow）。它們既可嵌入應用，也能單飛。
Supabase 的數據藍圖
大家知道 Supabase 是 Postgres 服務商，我們花了 5 年打造讓開發者舒爽的數據庫平臺，這仍是主航道。
不同的是，我們不止做 Postgres（雖然梗圖[37]挺火）。我們還提供 Supabase Storage[38]，一套兼容 S3 的對象存儲。未來，Supabase 聚焦的不是“一個數據庫”，而是“所有數據”：
?給我們維護的所有開源工具加上 OTel。?在 Supabase Storage 引入 Iceberg。?在 Supabase ETL[39] 里打通 Postgres ? Iceberg 零 ETL。?通過擴展和 FDW，讓 Postgres 能讀能寫 Iceberg。
接下來，我們押注三大開放數據標準：Postgres、OTel、Iceberg。敬請期待。
老馮點評
Supabase 是我最欣賞的數據庫創業公司，他們的創始人認知水平非常在線。 例如在三年前 OpenAI 插件帶火向量數據庫賽道之前，Supabase 就已經發掘出 pgvector 進行 RAG 的玩法了。
YC S20 的項目走過五年發展到今天，已經是估值 2B 的獨角獸了。目前 YC 80% 的初創公司都在用 Supabase 起步。 目前有小道消息稱 OpenAI 即將收購 Supabase，如果是真的，那他們也算功德圓滿，實至名歸。
關于 Postgres
老馮非常認同 Paul 的觀點，Postgres 已經成為 OLTP 世界的事實標準。 但至少在當下，還有幾件事是 PostgreSQL “不擅長” （不是做不到）的：
?遙測?海量分析?對象存儲
所以如果你想要提供一個真正 “完全覆蓋” 的數據基礎設施，那么光有 PostgreSQL 是不行的。
我的意思是，你可以使用 TimescaleDB 擴展存儲遙測數據，但體驗與表現是比不上 Prometheus，VictoriaMetrics 的等專用 APM 組件的。
你確實可以用原生 PG，TimescaleDB，Citus，以及好幾個 DuckDB 縫合擴展做數倉 —— 盡管我認為 DuckDB PG 縫合有潛力解決這個問題，但至少在當下，當數據量超過幾十個 TB 時，專用數倉的性能依然還是壓著 PG 打的。
有一些 “邪路” 可以將 PG 作為文件系統，例如 JuiceFS，但這僅適用于小規模的數據存儲（也許幾十GB？），海量 PB 級對象存儲依然是原生 PG 所望塵莫及的。
圖片
至于其他的細分領域，比如向量數據庫，文檔數據庫，地理空間數據庫，時序數據庫，消息隊列，全文檢索引擎，乃至是圖數據庫，PostgreSQL 都已經 “足夠好” 了。 留給其他產品的只剩下一個極端場景專用組件的 Niche，不會再有其他這種體量的玩家出現了。
圖片
因此，在我做 Pigsty 的時候，也是用相同的思路構建的，以 PostgreSQL 為核心，以可觀測性作為這個發行版的基石（Postgres in Grafana Style：這是最初的縮寫），以同心圓的方式對外攤大餅。 用 MinIO 補足對象存儲，用 DuckDB / Greenplum 補足數倉分析能力，最后用數量驚人的擴展插件來覆蓋其他細分領域。
其實在這一點上， Pigsty 跟 Supabase 很像，只不過人家是 2B 獨角獸，老馮是數據庫個體戶，哈哈。但其實只要戰略選對了，也不是不能打，比如， Supabase 騎在 PostgreSQL 肩膀上，而我可以騎在 Supabase 的肩膀上。
關于開源
Paul 說關于開源的三點精髓，第三點他領悟的是最慢的：
有沒有商業中立、無廠商綁架；更妙的是，有 多家 公司背書而非一家獨大。
其實我非常理解 Paul 的感受，在前兩年，Supabase 的想法可能是 —— “我要占領開源道德高地，但是也要用 PG 擴展構建自己的商業壁壘。”
雖然 Supabase 提供了 Docker Compose 自建模板，但那個數據庫容器鏡像充其量就是個玩具，而且里面包含著隱藏的壁壘。 主要是他們自己用 Rust 寫了幾個擴展插件，這幾個擴展插件雖然是開源的，但打包構建的知識并沒有在社區普及 —— 你無法指望讓用戶自己去編譯這些東西。
老馮就干了件 “缺德” 或者說 “有德” 的事（取決于廠家還是用戶視角），把他們的擴展插件全都編譯打包成了 10 大 Linux 主流系統下的 RPM/DEB 包， 這樣你就可以真的在自己的 PostgreSQL 上自建 Supabase 了。我們還提供了一個模板，可以在一臺裸服務器上自建 Supabase，目前是 Supabase 官方推薦的三個三方自建教程之一。
圖片
Supabase 還在想其他方法構建壁壘，例如他們去年收購了 OrioleDB，一個云原生，無膨脹的 PostgreSQL 存儲引擎擴展（需要Patch內核）。 還沒等正式 GA 上線，老馮就也已經打好了 OrioleDB 的 RPM/DEB 包，供用戶自建使用了。
圖片
我估計 Paul 的心情是復雜的，一方面他想要將用戶鎖定在 Supabase 云服務上，看到別人真的用開源來拆臺，心里肯定不爽。 但另一方面正是這些三方社區廠商的努力，反而讓 Supabase 開枝散葉，不是一個 “只有我提供” 的東西，才有了開源的醍醐味。 所以最后也釋然了，坦然接受了這種現狀。
但這件事也對老馮有所觸動，我也開始思考，Pigsty 作為一個開源項目，是否也有類似的 “開源三信條”？
老實說，老馮很懷念全職創業前的那種狀態，完全不考慮商業化，為了興趣，熱情，公益而開源，所以使用的是 Apache 2.0 協議。 后來因為拿投資人錢要有一個交代，所以把協議修改為更嚴格的 AGPLv3 ，目標是為了阻止云廠商與同行白嫖。 但既然現在我又成了數據庫個體戶，其實也是可以回到那種開源初心狀態的 —— “反正俺也不靠這個賺錢”。
References
[1]?Postgres:https://www.postgresql.org/
[2]OTel:https://opentelemetry.io/
[3]Iceberg:https://iceberg.apache.org/
[4]OSI 核準:https://opensource.org/licenses
[5]顛覆式創新:https://en.wikipedia.org/wiki/Disruptive_innovation
[6]我們堅信:https://supabase.com/docs/guides/getting-started/architecture#everything-is-portable
[7]wire 協議:https://www.postgresql.org/docs/current/protocol.html
[8]PostgreSQL License:https://www.postgresql.org/about/licence/
[9]OTel:https://opentelemetry.io/
[10]頗為復雜:https://news.ycombinator.com/item?id=42655102
[11]Datadog:https://docs.datadoghq.com/integrations/otel/
[12]Honeycomb:https://docs.honeycomb.io/send-data/opentelemetry/
[13]Grafana Labs:https://grafana.com/grafana/dashboards/15983-opentelemetry-collector/
[14]Elastic:https://www.elastic.co/docs/solutions/observability/apm/use-opentelemetry-with-apm
[15]SigNoz:https://github.com/SigNoz/signoz
[16]OpenObserve:https://github.com/openobserve/openobserve
[17]OTel 工具集:https://github.com/open-telemetry/opentelemetry-collector
[18]開放表格式:https://www.startdataengineering.com/post/what_why_table_format/
[19]DeltaLake:https://delta.io/
[20]Hudi:https://hudi.apache.org/
[21]Iceberg:https://iceberg.apache.org/
[22]Databricks:https://docs.databricks.com/aws/en/delta/uniform
[23]Snowflake:https://docs.snowflake.com/en/user-guide/tables-iceberg
[24]ClickHouse:https://clickhouse.com/docs/engines/table-engines/integrations/iceberg
[25]S3 Tables:https://aws.amazon.com/blogs/aws/new-amazon-s3-tables-storage-optimized-for-analytics-workloads/
[26]Conditional Writes:https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3-conditional-writes/
[27]S3 Express:https://aws.amazon.com/blogs/aws/new-amazon-s3-express-one-zone-high-performance-storage-class/
[28]逆天降價 85%:https://aws.amazon.com/blogs/aws/up-to-85-price-reductions-for-amazon-s3-express-one-zone/
[29]pg_mooncake:https://github.com/Mooncake-Labs/pg_mooncake
[30]pg_duckdb:https://github.com/duckdb/pg_duckdb
[31]Iceberg FDW:https://github.com/supabase/wrappers/pull/462
[32]DuckDB:https://duckdb.org/2021/10/29/duckdb-wasm.html
[33]云后端存儲:https://sqlite.org/cloudsqlite/doc/trunk/www/index.wiki
[34]turbopuffer:https://turbopuffer.com/
[35]SlateDB:https://slatedb.io/
[36]Tonbo:https://tonbo.io/
[37]梗圖:https://itsjustpostgres.com/
[38]Supabase Storage:https://supabase.com/storage
[39]Supabase ETL:?https://github.com/supabase/supabase_etl
