向量数据库和pgvector到底怎么选？感觉自己掉进坑里了

几百万条数据其实不算大规模，但也不至于pgvector就扛不住，p95四百多毫秒大概率是索引没调对。你用的什么索引？HNSW的参数m和ef_construction调过没？默认那套参数在几百万级别下基本就是自废武功，还有ef_search也得往上拉，不然召回率和延迟都难看。另外几百万条如果维度是1536，内存占用也不小，shared_buffers和work_mem这些也得跟着调，不然全走磁盘IO了延迟能好看才怪。我这边八百万条用pgvector，HNSW加上合理的参数，p95稳定在30ms以内，所以真不一定是pgvector的问题。当然如果你QPS很高、并发一上来，Postgres那套连接模型确实会拖后腿，这时候Qdrant或者Milvus的独立架构就有优势了。建议先用pgbench或者你自己的压测脚本把瓶颈定位清楚，看看到底是索引扫描慢还是IO等待，别急着换轮子，换完发现还是四百毫秒那就尴尬了。

几百万条其实不算大，pgvector扛得住，400ms大概率是索引没调好。先看看你建的HNSW还是IVFFlat，ivfflat的lists和probes参数不调，延迟很容易炸。另外几百万条还用OpenAI那1536维，内存和计算都吃紧，可以考虑降维或者量化。真要换的话Qdrant部署比Milvus轻，但有那功夫不如先把explain analyze跑一遍，别急着甩锅给pgvector。

几百万条不算大规模，pgvector 扛得住，问题大概率出在索引和查询方式上。先检查下 HNSW 索引建了没，ef_search 参数调过没，还有 embedding 维度是不是太高了。我之前也是类似数据量，把索引从 IVFFlat 换成 HNSW 后 p95 直接从 300ms 降到 40ms 左右。真要换的话 Qdrant 部署简单些，但别指望换个库就能无脑解决，查询逻辑和过滤条件的设计才是大头。

几百万条其实不算大，pgvector扛得住，400ms大概率是索引没调好。先检查下HNSW的m和ef_search参数，还有是不是每次查询都全表扫了。我之前类似数据量调完索引能压到几十毫秒，别急着换库。真要换Qdrant成本也不低，先花半天把执行计划看一遍再说。