Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D12 Long-Term Memory: pgvector, Embeddings, Chunking, the memory_search Tool

• How does pgvector compare with a dedicated vector database, and how would you choose?pgvector 和专用向量数据库相比，优劣分别是什么？你会怎么选？

  Common in ChinaCommon overseasIntermediate#vector-database#pgvector#architecture

  How to reason about it · think before answering

  1. This is a judgment question, not a feature-recital. Opening with 'Milvus does sharding, Qdrant filters better' carries no signal — they want your decision criteria and whether you have priced the operational overhead.
  2. Offer three questions that make the choice derivable: what scale, does it need to commit in the same transaction as business tables, and how complex is the metadata filtering.
  3. pgvector wins on the last two: memories live in the same database as the business tables, so writing a memory and updating a run share one transaction; filtering by user is an ordinary WHERE clause; backups, monitoring, pooling and migrations are all reused. The line that shows operational experience is that one more stateful service usually becomes the bottleneck before vector search performance does.
  4. Be honest about the ceiling: past roughly ten million vectors in one table, HNSW index builds eat memory and write amplification shows; ANN plus metadata filtering is weaker than a purpose-built engine; horizontal scaling is whatever Postgres gives you. Refusing to name downsides reads as salesmanship.
  5. Commit to a rule: under a million vectors, needing joins or shared transactions, small team — pgvector. Tens of millions, retrieval as the primary workload, someone owning the service — dedicated store. Do not start with the dedicated store on day one.
  6. Expect the follow-up on migration cost. Switching stores does not require re-embedding — vectors belong to the model, not the store, so export and import; the cost is dual-write and rollout. Switching the embedding model is what forces a full recompute, and that is the real lock-in.

  分析过程 · 先想清楚再作答

  1. 这题考的是选型判断力，不是产品参数背诵。开口就报「Milvus 支持分布式、Qdrant 过滤更强」是最没有区分度的答法——面试官想知道你按什么判据选，以及你有没有算过运维成本。
  2. 先给三个提问维度，把选型变成可推导的：数据量到什么量级、要不要和业务表在同一个事务里提交、过滤条件复不复杂。这三问能覆盖绝大多数真实场景。
  3. pgvector 的赢面几乎全在后两问上：记忆表和业务表在同一个库，写记忆和更新执行记录可以放进同一个事务；按用户过滤就是普通 where 条件；备份、监控、连接池、迁移工具全部复用。**多一个有状态服务的运维成本，通常比向量检索的性能更早成为瓶颈**——这句话最能体现你上过线。
  4. 再诚实地说它的天花板：单表到千万级向量时 HNSW 索引构建吃内存、写入放大明显，ANN 与元数据过滤的融合不如专用库，水平扩展只能靠 Postgres 自己那一套。不肯说缺点的人会被认为在推销。
  5. 结论要能写死：百万级以内、需要和业务表一起过滤或同事务提交、团队人手紧，用 pgvector；上千万条、检索本身就是主要负载、有专人维护，上专用库。别在第一天就选专用库。
  6. 可以预期的追问：以后想换库，迁移成本大不大？答案会让很多人意外——换库不用重算 embedding，向量是模型产出的，跟存它的库无关，导出导入即可，成本主要在双写和灰度。真正要全量重算的是换 embedding 模型，那才是硬锁定。

  Key points

  • Three criteria: scale, need for same-transaction commits with business tables, and filtering complexity
  • pgvector gives one database, one transaction, ordinary SQL filters and zero new operations — often worth more than raw performance
  • Its ceiling: memory-hungry index builds and write amplification at tens of millions, weaker ANN-plus-filter fusion, scaling limited to Postgres
  • Dedicated stores buy sharding, better filtered ANN and hybrid search, at the price of another stateful service to back up and monitor
  • Changing stores needs no re-embedding; changing the embedding model does — the lock-in is the model, not the database

  答题要点

  • 三个判据：数据量级、要不要和业务表同事务提交、元数据过滤复不复杂
  • pgvector 的优势是同库同事务、普通 SQL 过滤、运维零新增——少一个有状态服务往往比性能更值钱
  • pgvector 的天花板：千万级向量时索引构建吃内存、写入放大、ANN 与过滤融合弱、扩展受限于 Postgres
  • 专用向量库给的是分布式分片、更强的过滤与 ANN 融合、混合检索，代价是多一个要备份要监控的有状态服务
  • 换向量库不用重算 embedding；换 embedding 模型才要全量重算，真正的锁定点是模型不是库