# Supermemory 边缘 PostgreSQL 架构解析 > 剖析 Supermemory 如何通过 Cloudflare Workers 与 Durable Objects 的边缘协同，实现亚 400 毫秒的记忆检索延迟，探讨边缘优先架构的工程权衡。 ## 元数据 - 路径: /posts/2026/01/27/supermemory-edge-postgres-architecture/ - 发布时间: 2026-01-27T12:18:50+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 站点: https://blog.hotdry.top ## 正文 在人工智能应用蓬勃发展的当下，如何让 AI 系统以接近人类思考的速度访问长期记忆，已成为工程实践中的核心挑战。传统架构将数据存储在遥远的中心化数据中心，网络往返延迟往往成为制约用户体验的瓶颈。Supermemory 作为一款面向 AI 时代的记忆引擎，选择了一条颇具前瞻性的技术路径：将整个系统部署在 Cloudflare 的全球边缘网络上，通过 Hono 框架构建无服务器 API 层，结合 PostgreSQL 与 Durable Objects 的协同工作，实现了亚 400 毫秒的记忆检索延迟。这一架构选择并非简单的技术堆砌，而是对边缘计算能力与分布式系统理论的深度融合，值得我们从工程实践的角度深入剖析。 ## 边缘优先的架构设计理念 Supermemory 的技术团队在设计系统架构时，面临着所有 AI 记忆系统都必须回答的核心问题：如何在保证数据持久性的前提下，最小化用户查询的端到端延迟。传统的解决方案通常采用多级缓存策略，在应用服务器与数据库之间插入 Redis、Memcached 等缓存层，以空间换时间的思路来降低延迟。然而，这种方案在面对全球分布的用户群体时，缓存命中率难以保证，不同地区的用户依然需要承受跨境网络带来的固有权衡。Supermemory 的答案更为激进：将计算与存储一同推向网络的边缘，让用户的请求在地理上最近的节点得到处理，从根本上消除了长距离网络传输的时间开销。 这一设计理念的实现依赖于 Cloudflare 提供的开发者平台能力。Cloudflare 在全球部署了超过 300 个数据中心，形成了覆盖范围极广的边缘网络。每个数据中心都运行着无服务器计算环境 Workers，以及持久化计算单元 Durable Objects，使得开发者可以在边缘节点上运行完整的应用逻辑。Supermemory 将其基于 Hono 框架的 API 服务部署在这些边缘节点上，用户发起查询时，请求会被智能路由到地理位置最近的 Cloudflare 数据中心，由当地的 Worker 实例处理。这种架构的优势在于，无论用户身处世界何处，其请求所经过的网络跳数都被控制在极少的范围内，端到端延迟得以显著降低。 ## Hono 框架与边缘计算的契合 在选择 API 框架时，Supermemory 采用了 Hono 而非传统的 Express 或 Fastify，这一选择蕴含着深刻的工程考量。Hono 是一个专为边缘计算场景设计的高性能 Web 框架，其核心优势在于极小的运行时开销和对 Web 标准的严格遵循。与传统 Node.js 框架相比，Hono 不依赖庞大的运行时环境，可以直接运行在 Cloudflare Workers、Vercel Edge Functions、Deno Deploy 等多种边缘计算平台上。这种跨平台特性使得基于 Hono 构建的应用具有良好的可移植性，工程团队无需为不同的边缘计算供应商重写代码。 从性能角度来看，Hono 的路由机制基于 Trie 树结构实现，能够在常数时间内完成请求路径的匹配，相比传统的线性遍历或正则匹配具有显著的性能优势。在高并发场景下，这一差异尤为明显。此外，Hono 内置的中间件系统采用了洋葱模型，开发者可以灵活地组合认证、日志、缓存等功能模块，而不必担心中间件执行顺序带来的副作用。Supermemory 利用这一特性，实现了统一的请求拦截与响应处理逻辑，为后续的功能扩展奠定了坚实的基础。值得注意的是，Hono 的 API 设计完全遵循 Fetch API 标准，这意味着在 Cloudflare Workers 环境中，请求与响应的处理方式与浏览器端保持一致，降低了跨环境开发的心智负担。 ## PostgreSQL 在边缘的工程实践 数据存储层是整个系统架构中最具挑战性的部分。Supermemory 选择 PostgreSQL 作为主数据库，并使用 Drizzle ORM 进行类型安全的查询构建。这一选择的背后是对关系型数据库与向量搜索能力的双重需求。PostgreSQL 的 pgvector 扩展提供了高效的向量相似度搜索功能，使得 Supermemory 能够在同一个数据库中完成结构化数据与语义向量的统一存储与查询，避免了维护多套系统带来的运维复杂度。 然而，在边缘计算环境下运行 PostgreSQL 并非易事。传统的 PostgreSQL 部署假设数据库实例位于稳定的数据中心，拥有可靠的电力供应与高速的网络连接。边缘环境则截然不同，每个节点的资源受限，且节点之间的网络连接质量参差不齐。Cloudflare 针对这一挑战提供了分布式 PostgreSQL 集群解决方案，通过在多个边缘节点上复制数据，并利用共识算法保证数据一致性。但分布式复制带来的延迟问题依然存在，特别是在写入操作时，主节点与从节点之间的同步需要时间，在此期间读取到的数据可能是稍旧的版本。Supermemory 在工程实践中采用了读写分离策略，将读取请求路由到最近的副本节点，写入请求则发往主节点，通过牺牲部分写入性能来换取读取延迟的最小化。 Drizzle ORM 在这一架构中扮演着重要的抽象层角色。它提供了与数据库运行时的解耦能力，使得切换底层存储引擎或调整连接策略时，上层业务代码无需大规模改动。Drizzle 的查询构建器采用链式 API 设计，类型推导能力强，IDE 的自动补全功能可以显著降低查询编写的错误率。在边缘计算场景下，这种类型安全的优势尤为重要，因为边缘环境的调试手段相对有限，编译期发现错误远比运行时排查问题更加高效。 ## Durable Objects 与状态管理 Cloudflare Durable Objects 是 Supermemory 架构中的另一关键组件，它解决了边缘计算环境中状态管理的难题。传统的无服务器函数是无状态的，每次调用之间相互独立，这使得实现需要跨请求保持状态的逻辑变得困难。Durable Objects 提供了持久化的命名空间，每个对象实例拥有独占的存储空间，对象之间通过唯一的 ID 进行寻址与通信。这种设计模式与 Actor 模型高度契合，每个对象如同一个独立的 Actor，通过消息传递与其他对象交互，避免了共享状态带来的并发问题。 Supermemory 利用 Durable Objects 实现了多项核心功能。首先是会话状态的本地化存储，用户的认证会话信息可以直接保存在 Durable Objects 中，而无需依赖外部的 Redis 或数据库，减少了网络往返次数。其次是 WebSocket 连接的持久化管理，对于需要实时推送的场景，Durable Objects 可以保持长连接的活跃状态，并在连接断开时自动重连。此外，Durable Objects 还被用于实现分布式锁与任务队列，确保在分布式环境下并发操作的正确性。 从技术参数来看，每个 Durable Object 实例默认拥有 1GB 的存储配额，对于大多数应用场景而言已经绑绑有余。对于需要更大存储空间的应用，可以通过分区策略将数据分散到多个对象实例中。对象的创建与销毁由系统自动管理，当对象长期未访问时，系统会将其回收以释放资源；当新的请求到达时，系统会快速重建对象实例。这种弹性伸缩能力使得开发者无需预先规划容量，可以根据实际的访问模式动态调整资源使用。 ## 工程权衡与性能参数 任何架构选择都伴随着权衡，Supermemory 的边缘优先架构也不例外。从一致性角度来看，由于数据在多个边缘节点之间复制，读取操作可能无法总是获取到最新的写入结果。Supermemory 通过多种策略来缓解这一问题：在关键业务路径上强制读取主节点以获取强一致性保证；在非关键路径上接受最终一致性以换取更低的延迟；在 UI 层面通过乐观更新与冲突提示来透明化处理数据同步的延迟。这些策略的组合使用，使得系统在大多数场景下能够提供良好的用户体验，同时在必要时保证数据正确性。 从成本角度来看，边缘计算的商业模式与传统托管存在显著差异。Cloudflare Workers 的计费基于请求次数与 CPU 执行时间，而非实例数量或占用时长。这种计费方式对于流量波动较大的应用非常友好，无需为空闲时间支付闲置成本。然而，Durable Objects 的计费则包含了存储费用与活跃实例费用，工程团队需要根据实际的数据量与访问模式进行成本优化。Supermemory 在实践中采用了数据冷热分离策略，热数据保存在 Durable Objects 中以获得最快的访问速度，冷数据则迁移到对象存储中以降低成本。 在性能调优方面，Supermemory 的工程团队积累了一系列可复用的参数配置。对于 Hono 框架，建议启用 gzip 压缩以减少响应体大小，设置合理的请求超时时间以避免慢请求占用过多资源。对于 PostgreSQL 连接管理，建议使用连接池并设置适当的池大小，避免在高并发场景下耗尽数据库连接。对于向量搜索，建议根据准确率需求调整搜索的 k 值与相似度阈值，在搜索质量与响应速度之间找到最佳平衡点。 ## 监控与可观测性实践 在分布式边缘架构中，监控与可观测性的重要性被提升到了新的高度。由于请求可能由全球任意一个边缘节点处理，传统的日志聚合与指标收集方式需要相应的调整。Supermemory 采用了多层次的监控策略，在应用层面，通过结构化日志记录每个请求的路由路径、处理耗时与响应状态；在基础设施层面，利用 Cloudflare 提供的 Analytics 能力监控请求量、错误率与延迟分布；在数据库层面，采集 PostgreSQL 的慢查询日志与连接池使用情况，及时发现潜在的性能瓶颈。 错误追踪方面，Supermemory 集成了 Sentry 作为异常监控平台，并配置了自动上传源映射（Source Maps）的 CI/CD 流程。当边缘节点发生异常时，堆栈信息可以被准确还原，帮助开发团队快速定位问题根因。此外，系统还实现了自定义的健康检查接口，定期探测 API 可用性、数据库连通性与向量搜索功能，在用户感知到问题之前主动发现并修复故障。 ## 面向未来的架构演进 Supermemory 的边缘优先架构为 AI 记忆系统的设计提供了一个有价值的参考范例。随着边缘计算生态的持续成熟，我们可以预见更多应用将采用类似的架构策略。未来有几个值得关注的技术方向：首先是 Durable Objects 对 SQLite 的原生支持，这将使得边缘数据库的能力大幅增强；其次是边缘 AI 推理的兴起，未来的边缘节点可能不仅能处理请求路由，还能运行轻量级的模型推理；最后是边缘间通信协议的优化，随着服务网格技术在边缘的落地，跨节点的服务调用将变得更加可靠与高效。 Supermemory 的实践表明，边缘计算已经从概念验证阶段走向生产可用阶段。对于追求极致用户体验的应用而言，将计算推向边缘已经不再是可选项，而是构建差异化竞争力的必要手段。当然，这一路径也带来了新的工程挑战，包括分布式一致性、跨区域数据同步与复杂的调试流程等。Supermemory 的工程团队通过选择成熟的框架、构建完善的监控体系、持续迭代优化，在这些挑战面前积累了宝贵的实践经验。这些经验对于正在探索边缘计算的技术团队而言，具有重要的参考价值。 **资料来源**： 1. Supermemory 系统架构（https://deepwiki.com/supermemoryai/supermemory/1.1-system-architecture） 2. Cloudflare 分布式 PostgreSQL 运维实践（https://infoq.com/articles/cloudflare-distributed-postgres） ## 同分类近期文章 ### [NVIDIA PersonaPlex 双重条件提示工程与全双工架构解析](/posts/2026/04/09/nvidia-personaplex-dual-conditioning-architecture/) - 日期: 2026-04-09T03:04:25+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 NVIDIA PersonaPlex 的双流架构设计、文本提示与语音提示的双重条件机制，以及如何在单模型中实现实时全双工对话与角色切换。 ### [ai-hedge-fund：多代理AI对冲基金的架构设计与信号聚合机制](/posts/2026/04/09/multi-agent-ai-hedge-fund-architecture/) - 日期: 2026-04-09T01:49:57+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析GitHub Trending项目ai-hedge-fund的多代理架构，探讨19个专业角色分工、信号生成管线与风控自动化的工程实现。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation-framework/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [LiteRT-LM C++ 推理运行时：边缘设备的量化、算子融合与内存管理实践](/posts/2026/04/08/litert-lm-cpp-inference-runtime-quantization-fusion-memory/) - 日期: 2026-04-08T21:52:31+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 LiteRT-LM 在边缘设备上的 C++ 推理运行时，聚焦量化策略配置、算子融合模式与内存管理的工程化实践参数。