現代 Web 應用程式的開發趨勢傾向於將功能解耦，將運算、資料庫與快取分開部署在不同的服務中。這種做法雖然提升了單一組件的靈活性，但卻引入了所謂的多系統堆疊（Multi-System Stack）問題。在這種架構下，每一次的資料請求都必須經過網路傳輸，從伺服器端函數跳轉到遠端資料庫或快取系統，這些網路跳轉（Network Hop）累積起來的延遲，在處理高度個人化且需要即時更新的資料時，會成為顯著的效能瓶頸。
資料庫平台 Harper 針對此問題提出了一種截然不同的觀點，主張採用單一運行時架構（Single-Runtime Architecture）。這種設計的核心理念是將應用程式碼與資料直接放置在同一個運行環境中，使資料存取從原本的網路請求轉變為記憶體內的函數調用。與目前業界流行將運算與儲存分離的趨勢（例如 Databricks 的 Lakebase）相反，Harper 試圖透過將層級合併來簡化運作複雜度並降低成本。
為了驗證此理論，Harper 進行了一項基準測試，將同一個產品目錄應用程式分別部署在兩種截然不同的架構中。第一組是 Harper 的單一系統，將資料、運算與訊息傳遞共置於同一節點；第二組則是典型的 Vercel 堆疊，整合了 Vercel Functions 作為運算層、Neon Postgres 作為資料庫、Upstash Redis 作為快取，以及 Ably 處理即時通訊。兩組測試使用相同的使用者介面與資料契約，唯一的變數僅為底層架構。
測試結果顯示，在處理即時且個人化的資料路徑時，Harper 的表現大幅領先。由於資料存取是在程序內（In-process）完成，其存取時間約為 0.4 毫秒，而 Vercel 堆疊因需經過網路跳轉，延遲約為 3 毫秒。當頁面需要抓取的個人化資料量增加時，這種效能差距會進一步擴大，在某些場景下，Harper 的速度甚至快了 14 倍。
然而，單一運行時架構並非在所有場景都佔優勢。測試發現，當面對極高併發的扇出負載（Fan-out Load，指單一請求觸發大量後續操作）時，Vercel 的伺服器端無伺服器（Serverless）自動擴展能力表現更佳。Harper 的單一節點在併發量增加到一定程度後會觸及吞吐量上限。因此，兩者的適用場景分明：Vercel 適合快取比例高、僅需廣播即時訊息或需要極強擴展能力的邊緣傳遞內容；而 Harper 則在需要頻繁讀寫、對資料新鮮度要求高且涉及大量個人化運算的場景中具有壓倒性優勢。
在技術實作上，Harper 透過將整個單元複製到每個區域的節點並保持全球同步，確保使用者能由最近的節點以程序內存取方式獲取資料。為了進一步優化，Harper 在最新的 5.2 版本中引入了紀錄快取（Record Cache），使重複讀取的速度提升 5 到 8 倍。此外，該版本解決了一個關鍵的技術缺陷：過去資料庫的提交（Commit）操作會與 Node.js 的 libuv 工作執行緒池共享，導致大量寫入時會阻塞其他不相關的程序工作。透過將提交路徑隔離，Harper 成功將不相關檔案系統調用的 p99 延遲從 223.7 毫秒大幅降低至 2.6 毫秒。
儘管單一運行時架構帶來了極低的延遲，但其限制在於記憶體容量。目前的基準測試是在溫熱的記憶體資料集（Warm, in-memory dataset）下進行的，如果工作集（Working Set）的大小超過了可用記憶體，其性能優勢可能會縮小。整體而言，Harper 的嘗試為開發者提供了一種思考方向：在追求系統解耦的同時，應重新評估網路跳轉所帶來的成本，並在適當的場景下考慮將運算與資料重新整合，以獲取極致的回應速度。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。