向量数据库自建 vs 托管：数据量在 1000 万以内时的 TCO 成本测算
在落地企业级 RAG（检索增强生成）与多模态搜索系统时，向量数据库（Vector Database）的选型往往是架构评审会上的焦点议题：
- 算法同学往往倾向于直接上最热门的专用分布式向量数据库（如 Milvus 分布式集群、Pinecone、Zilliz Cloud 托管版）；
- 运维同学担心自建分布式集群的高昂维护成本（需要同时维护 MinIO、Pulsar、ETCD 等一堆组件）；
- 老板和财务则死死盯住每个月的云账单开销。
很多中小团队在数据量只有几十万到几百万条时，就盲目搭建了一套庞大的分布式 Milvus 集群，结果每个月光服务器和运维人力成本就烧掉几万元，实际利用率却不足 5%。
今天我们基于真实的千万元级数据量（1000 万条 1024 维向量），从硬件资源、云托管账单、备份容灾与工程运维四个维度，彻底算清自建（PGVector / Qdrant）vs 公有云托管（Zilliz Cloud / DashVector）的总体拥有成本（TCO, Total Cost of Ownership）。
一、物理基准测算：1000 万条 1024 维向量需要多少资源？
1. 内存与磁盘裸容量计算
- 向量维度：1024 Float32（单向量占用 $1024 \times 4\text{ Bytes} = 4\text{ KB}$）；
- 裸向量数据量：$10,000,000 \times 4\text{ KB} = 40\text{ GB}$；
- HNSW 向量索引开销：HNSW 图索引通常需要裸数据 1.2~1.5 倍的额外内存开销，约为 $50\text{ GB}$；
- 业务元数据（Metadata）与 Payload：文本 Chunk 内容、文档 ID、权限标签等，约占用 $30\text{ GB}$；
- 总内存需求（为保证毫秒级查询，索引必须常驻内存）：$40\text{ GB} + 50\text{ GB} = 90\text{ GB}$。
- 总磁盘存储需求：$150\text{ GB}$ 左右（建议配置 NVMe SSD）。
flowchart TD Data[1000 万条 1024 维向量] --> Calc[物理资源模型: 90G 内存 + 150G NVMe 存储] Calc --> Path1[方案 A: 公有云全托管 Serverless / 独占实例] Calc --> Path2[方案 B: 单机 PGVector (基于已有 PostgreSQL 实例)] Calc --> Path3[方案 C: 单机/轻量 Qdrant (Rust 编写, 内存效率极高)] Path1 & Path2 & Path3 --> TCO[TCO 综合对比: 硬件 + 运维 + 停机风险]二、三种典型落地路径的三年 TCO 成本账本
| 评估维度 | 方案 A: 商业托管版 (如 Zilliz Cloud / DashVector) | 方案 B: 单机 PGVector (已有 PG 库复用) | 方案 C: 单机 Docker Qdrant (独立部署) |
|---|---|---|---|
| 首年硬件/云实例开销 | ~4.5 万元/年 (按月付费，约 3800元/月) | 0 ~ 1.2 万元/年(复用现有 128G PG 实例) | 1.8 万元/年(1 台 16核 128G 云主机) |
| 首年运维人力折算 | 0.1 人月 (~1.5 万元) | 0.3 人月 (~4.5 万元，熟悉 PG 运维) | 0.5 人月 (~7.5 万元，需学习 Qdrant 调优) |
| 冷启动开发周期 | 1~2 天（开箱即用 API） | 3~5 天（安装 pgvector 插件） | 3~5 天（对接 REST/gRPC SDK） |
| 混合查询能力 | 依赖外部元数据过滤 | 极致原生 SQL Join（业务表无缝关联） | 优秀的 JSON Payload 过滤 |
| 第一年综合 TCO | 约 6.0 万元 | 约 5.7 万元 | 约 9.3 万元 |
三、各方案技术痛点与深度权衡
1. 方案 B：PGVector——千万级以下的最优解
如果团队内部本来就在深度使用 PostgreSQL，那么PGVector 绝对是 ROI 最高的选择：
- 零额外系统维护：无需新增独立的存储中间件，复用现有的 RDS 备份、主从高可用与监控体系；
- ACID 与跨表关联：可以直接写出
SELECT * FROM doc_chunks d JOIN user_perm u ON d.user_id = u.id ORDER BY embedding <=> $1 LIMIT 5，在单条 SQL 中完成权限过滤与向量检索，无需在应用层拼装数据。 - 局限性：当向量规模超过 2000 万条时，构建 HNSW 索引的耗时较长，内存消耗显著放大。
2. 方案 C：Qdrant——单机性能与内存压缩的王者
Qdrant 基于 Rust 编写，其核心黑科技在于向量标量量化（Scalar Quantization - SQ）：
- 开启 INT8 量化后，可以将 1024 维的内存占用直接从 90GB 压缩到 25GB 以内！
- 单台 8 核 32G 的低配云主机即可流畅跑满 1000 万数据量的并发查询，单机硬件成本直接下降 60%！
# qdrant_config.yaml 开启标量量化极限省内存 storage: quantization: scalar: type: int8 quantile: 0.99 always_ram: true # 极速加载常驻内存3. 方案 A：公有云托管——用金钱换时间的敏捷选择
适合研发团队不足 3 人的初创项目，不需要任何运维知识，随用随停。但在长期运行（2 年以上）的稳定业务中，累计账单将显著高于单机自建方案。
四、小厂架构师最终决策清单
- 向量数据量 < 500 万条：坚决使用 PGVector。直接把向量当成 PostgreSQL 的一个字段存，开发和运维成本最低；
- 向量数据量 500 万 ~ 2000 万条 且预算极其紧张：选用单机 Qdrant + INT8 量化，用单台 32G 内存的云主机硬扛；
- 向量数据量 > 5000 万条 且并发 QPS > 5000：此时单机内存已经见顶，启动Milvus 分布式集群或采购公有云托管版。
在千万级数据量之内，千万不要被“分布式”概念带偏。单机高配实例结合合理的量化手段，既能省下几十万运维预算，又能把查询延迟稳稳压在 20ms 以内。
