「從MQTT到SQL，中間隔著的不是技術，是工程團隊的加班夜。」一位物聯網架構師這樣吐槽。傳感器數據洪流涌向云端，寫入數據庫這一步卻常常成為瓶頸。

2010年代：MQTT成為事實標準

輕量級、發(fā)布訂閱模式、低帶寬友好——MQTT協議迅速占領物聯網通信層。設備端用MQTT上報溫濕度、位置、狀態(tài)，這步沒問題。但數據落地時，團隊面臨選擇：自建管道，還是買現成的？

TimescaleDB團隊（現Tiger Data）早期就盯上了這個斷層。他們發(fā)現，PostgreSQL生態(tài)缺一塊專門處理時序數據的拼圖。2017年TimescaleDB開源，核心思路很直接：在Postgres（一種開源關系型數據庫）內部做時序優(yōu)化，不改接口，只改引擎。

2020年代：流處理與SQL的融合實驗

MQTT代理（如Mosquitto、EMQX）負責接數據，下游需要流處理引擎做轉換。Kafka、Flink、Pulsar輪番登場，架構越堆越厚。一個典型物聯網項目可能同時運維：MQTT broker、消息隊列、流計算、時序數據庫、BI工具——五條技術棧，五個故障點。

Tiger Data的解法是把鏈條壓短。基于Postgres擴展，直接讓SQL語句消費MQTT流。不用額外部署流處理集群，一條INSERT...SELECT就能完成從Topic到表的映射。這對已有Postgres技術儲備的團隊，遷移成本幾乎為零。

2024年：BM25搜索進Postgres

傳感器數據不只是數字。設備日志、告警文本、位置標簽——這些半結構化信息需要被檢索。Tiger Data團隊發(fā)布pg_textsearch 1.0，把BM25算法（一種經典文本相關性評分模型）做到Postgres頁面存儲層。

關鍵細節(jié)：不是外掛搜索引擎，是原生擴展。這意味著時序查詢和全文搜索可以在同一事務里完成，不用跨系統JOIN。對于需要"2024年3月上海區(qū)域所有溫度異常且包含'壓縮機故障'描述的告警"這類查詢，延遲從秒級降到毫秒級。

產品邏輯：為什么選Postgres底座？

這不是技術浪漫，是商業(yè)計算。企業(yè)已有的人才儲備、BI工具鏈、權限體系、合規(guī)審計——全部基于SQL生態(tài)重建，成本極高。Tiger Data賭的是：時序數據庫的終局不是專用系統取代通用系統，而是通用系統吃掉專用場景。

但賭注也有代價。Postgres的存儲引擎為OLTP（在線事務處理）設計，時序數據的高吞吐寫入、冷熱分層、過期淘汰，都需要深度魔改。TimescaleDB的hypertable（超表）機制、連續(xù)聚合、壓縮算法，本質上是在Postgres架構約束內找最優(yōu)解。

一個待驗證的假設

物聯網數據管道正在收斂。從MQTT到SQL的"最后一公里"，會不會被云廠商的數據庫服務直接吞掉？如果設備直連托管數據庫成為默認選項，中間層的流處理引擎、ETL工具，還有多少獨立存在的價值？