前言
据权威IT媒体The Information报道，Databricks正在寻求收购Neon。Neon是一家销售开源PostgreSQL数据库商业版本的初创公司，据知情人士透露，此次收购的交易估值或突破10亿美元。若Databricks能成功收购，将显著增强其在AI领域的主导地位和技术实力。
Databricks对Neon的兴趣点与该引擎和AI应用（比如 AI 编码助手）贴切程度密不可分。Neon可以提供结构化数据、向量数据（即针对AI模型保存信息的数据结构）的支持，同时支持存算分离架构和分支能力（Branching），能快速地预置新数据库实例以及动态扩缩容。 AI 时代下的数据库并不需要“大而全”的产品堆砌，而是需要具备解决实际问题的“关键”能力。
1、什么是Neon
Neon是一款100%兼容PostgreSQL的Serverless数据库，旨在解决传统数据库的三大痛点：资源按峰值配置导致长期闲置浪费、创建测试分支耗时长且低效、运维复杂。它通过云原生架构深度改造PostgreSQL，而非简单云化，实现资源弹性与开箱即用的体验。云原生架构通过存算分离实现弹性、扩展性和高可用性，抽离传统数据库的Redo Log是实现存算分离的一种重要策略。Redo Log详细记录事务操作以保障故障恢复，自身也可以被视为一种数据存储形式。如AWS的Aurora、Microsoft Azure的Socrates都通过类似方式实现存算分离。Neon也是类似的思路，基于PostgresSQL数据库分离出WAL以实现存算分离，并基于此衍生出一些在AI时代更受青睐的特性，比如快速创建分支（Branching）。
Neon架构介绍
如图所示，Neon架构分为计算节点和存储层：
- 计算节点运行PostgreSQL，负责执行查询和事务，但不直接存储数据，而是通过写入日志WAL与存储层交互。
- 存储层负责持久化和管理数据，包含三个组件：
- Safekeeper：通过Paxos协议可靠存储WAL，确保数据持久性和高可用性。
- Pageserver：解析Safekeeper的WAL记录，生成不可变数据文件并存储到云对象存储，同时加速数据访问。
- 云对象存储：低成本、高持久性地保存最终数据，如AWS S3、阿里云OSS等。
通过存算分离架构，Neon实现了计算资源的弹性管理与存储资源的高效持久化，并且为下文中的特性提供了基础。
Neon特性介绍
▶︎ Branching
Neon的Branching功能允许用户快速创建主数据库分支用于测试/开发，且不影响主库（类似Git分支管理）。其核心源于数据以LSN（日志序列号）标记并采用LSM树合并存储（不修改原始数据），天然支持分支操作。这一特性在大模型驱动的Vibe Coding和MCP Server场景中发挥关键作用。
▶︎ Time Travel
Neon的Time Travel功能利用Pageserver中数据的LSN属性，使用户能够在任意指定的LSN位点启动一个Compute Node（PG），该节点仅能访问在该LSN位点之前的数据，从而实现对历史数据的访问。
▶︎ Autoscale & Autosuspend
Neon通过实时监控CPU和内存利用率，并借助K8s集群管理工具，实现自动扩缩容及自动启停（Autoscale & Autosuspend）：用户可设置资源使用范围的最大/最小值，系统据此动态调整实例规模，当实例连续5分钟无操作时，Neon会自动暂停实例，并在新任务到来时快速重启。
▶︎ 一写多读
与原生PG一样，都通过流复制实现一写多读，但原生PG需要多份存储，而Neon通过共享缓存层（Pageserver）主从节点可以从相同的数据源中获取，既节约了存储资源，又提供了即时的只读弹性。
2、Vibe Coding时代下的Neon：AI驱动的全栈开发新范式
随着大模型编码能力的指数级提升，"Vibe Coding"这一概念正颠覆传统软件开发模式，开发者甚至非技术人员可快速创建网站/APP原型。以Vercel V0、Lovable等工具为代表的Vibe Coding已实现设计稿精准还原，而成熟的后端存储是其从原型走向落地的核心突破。Neon凭借深度集成全栈生态和极致易用性，成为首选的托管数据库服务。例如，Vercel V0默认集成Neon，利用其Branching功能为每个设计迭代独立创建数据库沙盒，避免数据冲突。
Vercel V0提供Neon原生集成，让大模型直接操作Neon数据库
同时，随着MCP的普及，开发者正通过标准化接口将AI能力与数据库、文件系统、API等基础设施无缝连接。Neon通过Branching特性开放了数据库完全读写权限，即使AI操作异常，其沙盒隔离也能避免数据损毁。
Neon的架构设计在TP场景有着显著的优势，但在面对TB至PB级数据规模时，受限于PageServer的容量和OSS对象存储的高IO延迟与低吞吐特性，会出现扫描性能衰减、复杂查询响应缓慢等问题。
相比之下，阿里云瑶池旗下的云原生数据仓库AnalyticDB PostgreSQL 版专为海量数据分析场景设计，通过存算分离架构和全栈自研技术实现性能突破。
3、基于Neon架构的AnalyticDB PostgreSQL Serverless版
云原生数据仓库 AnalyticDB PostgreSQL 版（下文简称ADB PG）是一款分布式实时数仓，基于Neon Log Is The Database的思想，ADB PG从MPP架构升级到Severless形态，这种设计保留了Postgres的索引、主键去重、实时流式写入等所有特性。同时，在复杂分析场景中引入自研的行列混合存储引擎Beam和自研向量化执行引擎Laser，使得ADB PG在存算分离架构下依然具备极强的查询分析性能。ADB PG基于存算分离架构，构建了极致弹性、Virtual Warehouse、Time Travel+Branching等高阶能力。
ADB PG 存算分离架构图
ADB PG与Neon的能力对比
▶︎ Virtual Warehouse
借助Neon的一写多读能力，ADB PG Serverless引入Virtual Warehouse作为只读集群。这样的设计不仅提升了计算性能，还允许根据实时负载动态调整计算资源，实现灵活的扩展。通过这种横向扩展能力，ADB PG能够高效管理资源使用，确保在处理大规模分析任务时始终保持快速响应。
▶︎ Time Travel + Branching
ADB PG Serverless同样支持Branch与Time Travel的能力。由于ADB PG是分布式的，相对于Neon，我们需要进一步考虑分布式场景下的一致性。
1) 对于Branch能力，在ADB PG中，需要在Master Node与Compute Node之间建立一致性的LSN位点，我们通过周期性地在两阶段事务提交时加锁来获取全局一致性的LSN位点。
2) 在备份周期内，ADB PG存算分离形态可以通过Neon的Branch能力将元数据恢复到某个指定的全局一致性恢复位点上，就可以读取到对应位点的用户数据。
Severless下的自研引擎突破
区别于Neon的小规模TP场景，ADB PG聚焦海量数据分析场景，通过行列混存引擎Beam与向量化引擎Laser，突破存算分离架构的性能瓶颈，解决TB/PB级数据场景的计算效率问题。
核心挑战：OSS对象存储的天然限制
OSS对象存储的高延迟、低吞吐特性导致TB/PB级数据扫描性能衰减，影响查询效率。
自研技术突破：存储引擎与执行引擎双轮驱动
1、自研存储引擎优化
- 列裁剪+Zonemap过滤：精确按需读取字段，跳过无关数据块，减少I/O数据量 50%以上；
- 动态压缩技术：结合字典编码与通用压缩算法，降低带宽需求30%-70%；
- 弹性缓存架构：
- 智能预热+数据预取：动态加载高频数据并预测性加载冷数据；
- 无状态节点设计：支持低成本临时盘缓存（同等硬件成本下，缓存容量提升2.5倍）。
2、自研执行引擎突破
- 向量化执行：列式批量处理取代逐行迭代，计算效率提升10倍以上；
- SIMD指令加速：针对数值计算与字符串操作进行指令级优化，核心算子性能翻倍。
性能表现
- TPC-H基准测试（10TB数据）：缓存覆盖70%数据时，性能达存储弹性架构的90%+；
- 端到端查询性能：较PostgreSQL原生火山模型提升5倍以上，复杂分析场景优势更加显著。
4、总结
AnalyticDB PostgreSQL 版基于Neon架构隆重推出满足 AI 时代应用开发需求的Serverless版本，并且在这之上搭载了结构化分析、向量检索、BM25全文检索和图检索，通过一套引擎满足 AI 应用丰富的数据诉求，支持MCP和OpenAI协议，为企业全面拥抱 AI 配备了数据存储、分析和应用的 “关键” 能力，帮助企业火箭式启动跑赢时代！
了解更多
如您对技术细节感兴趣
欢迎钉钉搜索群号：11700737 or 钉钉扫码入群交流
