임베딩 차원이 두 배가 되면 원본 벡터 메모리도 정확히 두 배가 된다. 그런데 같은 1,183,514개·100차원 데이터셋에서도 Qdrant는 937MiB, Milvus는 4,195MiB를 기록해 4배 넘게 갈렸다출처. 그래서 RAG용 벡터DB 선택은 "어느 제품이 빠른가"가 아니라 "내 차원·벡터 수를 해당 엔진이 RAM에 어떻게 배치하는가"를 직접 재는 문제에 가깝다.
임베딩 차원이 늘면 벡터 DB 메모리는 정말 비례해서 커질까?
원본 벡터만 보면 그렇다. 벡터 수 × 차원 수 × 바이트 수 공식대로, 100만 개 1,536차원 FP32 벡터는 약 6.14GB(1,000,000×1,536×4)다. 차원을 768에서 1,536으로 늘리면 원본은 정확히 2배, 3,072로 늘리면 4배가 된다. 하지만 이건 "원본 벡터"만의 이야기다. HNSW 그래프, 메타데이터, 런타임 여유분이 더해지면 같은 차원·같은 벡터 수에서도 DB마다 실제 RAM 사용량이 크게 벌어진다.
- 원본 벡터 메모리는 차원에 선형 비례한다 — 이건 예측 가능하다
- 실제 운영 메모리는 인덱스 구조·GC 여유분·보조 프로세스에 따라 같은 조건에서도 수 배 차이 난다
- 100차원처럼 낮은 차원에서도 DB 선택에 따라 메모리 차이가 4배 이상 날 수 있다출처
- 1,024차원·225만 벡터 규모에서는 엔진별 피크 RAM이 17.0GB~62.4GB까지 벌어졌다출처
- 따라서 "몇 GB 필요한가"는 모델명이 아니라 벡터 수·차원·정밀도·인덱스 유형을 먼저 고정해야 답할 수 있는 질문이다
이 실험에서 검증하려는 건 하나다. 차원 수가 커질 때 원본 벡터 메모리의 선형 증가와, 실제 벡터DB가 보고하는 피크 RAM의 증가가 같은 기울기로 움직이는지, 아니면 엔진마다 다른 상수항·기울기를 갖는지를 공개 벤치마크로 확인하는 것이다.
실험을 어떻게 설계해야 차원과 메모리의 관계가 보일까?
변수를 하나씩 통제해야 차원의 효과만 분리된다. 동일한 문서 청크와 동일한 DB에서 384·768·1,024·1,536차원을 각각 측정하고, 벡터 수와 FP32/FP16, HNSW의 M·ef_construction, 검색 시 ef를 고정해야 한다. 측정 항목도 "피크 RAM" 한 줄로 끝내면 안 된다. 인덱스 생성 중 피크 RSS, 생성 완료 후 안정 상태 RSS, 질의 부하 중 p95·p99 RSS, 재시작 직후 캐시가 비어있는 로딩 시간을 따로 봐야 한다. 이 네 숫자가 같은 DB 안에서도 서로 다르게 움직이기 때문이다.
실제로 아래에서 다룰 공개 벤치마크들은 이 조건 중 일부만 공개했다. glove-100-angular는 m=16, ef_construction=200을 명시했고출처, bge-m3 조건은 코사인 거리·L2 정규화·시드 42까지 명시했다출처. 반면 1,536차원 지연 비교 자료는 하드웨어 사양이 충분히 공개되지 않아 보조 자료로만 쓸 수 있다.
100차원 공개 벤치마크는 무엇을 보여줄까?
낮은 차원에서도 DB 런타임 차이가 메모리를 지배한다는 걸 보여준다. Qdrant·Weaviate·Milvus·pgvector를 동일 장비에서 비교한 벤치마크는 glove-100-angular(1,183,514개, 100차원, HNSW)로 약 10,000개 질의를 평가했다출처. 피크 메모리는 Qdrant 937MiB, pgvector 2,765MiB, Weaviate 3,689MiB, Milvus 4,195MiB로 측정됐다. 디스크 사용량은 Qdrant 725MiB, pgvector 약 2.2GiB, Milvus 약 3GiB였다.
지연도 함께 봐야 균형이 맞는다. p95 지연은 Milvus·Weaviate가 약 3ms로 가장 낮았고, Qdrant 5.3ms, pgvector 6.3ms였다. 즉 이 조건에서 Milvus는 메모리를 가장 많이 쓰지만 지연은 가장 낮은 축에 속한다. 100차원은 최신 임베딩 모델의 768·1,024·1,536차원을 직접 대표하지 않으므로, 여기서 얻을 수 있는 결론은 "차원이 낮아도 메모리 격차가 생긴다"는 구조적 관찰까지다.
1,024차원 BGE-M3 조건으로 가면 그림이 달라질까?
규모가 커질수록 엔진 간 격차가 더 벌어진다. 7개 오픈소스 벡터DB를 bge-m3(1,024차원, FP32, 코사인, L2 정규화, k=10)로 비교한 벤치마크에서 50,000개 벡터 기준 피크 RAM은 Redis 559MB, Weaviate 1,201MB, LanceDB 1,574MB, Chroma 1,800MB, pgvector 2,024MB, Milvus 3,300MB였다출처. 225만 개 규모로 가면 인메모리 엔진의 피크 RAM이 17.0GB~62.4GB로 벌어져 절대 메모리 기준 약 3.7배 차이가 났다.
같은 1,024차원 조건에서 16GB 서버가 수용할 수 있는 벡터 수는 Redis 약 150만 개, Qdrant 약 370만 개, 디스크 기반 엔진 약 1,400만~2,700만 개로 제시됐다출처. 이 수치는 검색 방식과 인덱스가 달라 단순 성능 순위가 아니라 "메모리 상주 여부"를 비교하는 자료로 보는 게 맞다. 벡터당 메모리 산정표도 비슷한 방향을 가리킨다. 1,024차원 FP32 원본은 벡터당 4,096바이트인데, Milvus는 4,224바이트, Qdrant는 4,296바이트, Weaviate는 Go GC 여유분까지 포함해 5,533바이트로 제시됐다.
1,536차원급 임베딩에서는 메모리와 지연이 어떻게 보고됐을까?
원본 메모리는 100만 개 기준 약 6~7GB로 커지지만, 공개된 지연 수치의 재현성은 더 낮아진다. OpenAI text-embedding-ada-002 크기를 기준으로 한 비교에서 p50/p99 지연은 Qdrant 4ms/25ms, Redis 5ms/20ms, Milvus 6ms/35ms, Weaviate 12ms/65ms, pgvector 18ms/90ms로 보고됐다출처. 다른 비교 글은 1M·1,536차원 FP32 HNSW 데이터셋 전체 메모리를 대략 6~7GB로, pgvector HNSW p50 지연을 8~15ms로 설명한다출처.
문제는 이 두 자료 모두 장비 사양과 인덱스 파라미터, 캐시 상태가 100차원·1,024차원 벤치마크만큼 자세히 공개되지 않았다는 점이다. 1,536차원 FP32 원본만 약 6.14GB라는 계산값은 확실하지만, "Qdrant가 4ms"라는 숫자를 내 프로젝트의 근거로 쓰려면 같은 조건의 재현 코드가 있는지부터 확인해야 한다.
RAG 용도별로는 이 수치를 어떻게 적용해야 할까?
용도에 따라 봐야 할 숫자가 달라진다. PostgreSQL 중심의 소규모 사내 문서라면 pgvector가 운영 복잡도를 줄이는 선택지가 될 수 있지만, 1M·1,536차원 비교에서는 Qdrant보다 지연이 높게 측정된 자료가 있다출처. 메모리가 제한된 단일 노드라면 Qdrant가 100차원에서 937MiB, 1,024차원 산정표에서 벡터당 4,296바이트로 상대적으로 낮게 나타났지만, 이게 모든 데이터셋에서 항상 최소값이라는 뜻은 아니다. 대규모·분산·GPU 운영을 우선한다면 Milvus처럼 여러 프로세스(서버, etcd, MinIO)가 함께 도는 구조를 메모리 비용으로 받아들여야 한다. 인메모리 초저지연이 필요하면 Redis가 50,000개 조건에서 559MB로 가장 낮았지만 데이터가 커질수록 RAM에 직접 묶이는 구조가 제약이 된다. 디스크 중심 비용 최적화를 고려한다면 "RAM이 적으니 무조건 디스크 기반"이 아니라 실제 RAG에서 허용 가능한 p95 지연과 재시작 후 워밍업 시간을 함께 재야 한다.
이 벤치마크 수치를 내 프로젝트에 그대로 가져다 써도 될까?
그대로 가져다 쓰기는 어렵다. 100차원 벤치마크는 HNSW m=16, ef_construction=200을 명시했고 bge-m3 벤치마크는 시드 42까지 공개했지만, 1,536차원 지연 비교 두 건은 하드웨어와 재현 코드가 함께 검증되지 않았다. 2026년 기준으로 이 분야 벤치마크는 계속 업데이트되고 있어, 글에서 인용한 일부 자료는 2025년 시점의 재현 근거로 쓰려면 원문 공개일과 벤치마크 환경을 별도로 다시 확인해야 한다. 또한 벡터당 메모리 산정표는 컬렉션의 실제 payload, 삭제·갱신 비율, 세그먼트 수, 복제 수, 필터 인덱스, OS 캐시를 모두 동일하게 반영한 보편 공식이 아니라 "해당 벤치마크의 산정값"일 뿐이다. DB 버전, 임베딩 모델 버전, 벡터 자료형, 인덱스 파라미터, 서버 CPU·RAM·디스크, 데이터셋과 질의 세트 중 하나라도 바뀌면 수치는 재현되지 않을 수 있다.
이번 실험을 다시 돌려본다면 뭐가 남을까?
가장 크게 남는 질문은 "내 임베딩 차원에서의 실측값"이 공개 벤치마크에 없다는 점이다. 384차원이나 768차원처럼 흔히 쓰이는 중간 차원에 대한 DB별 피크 RAM 공개 자료는 이번 리서치에서 충분히 확보되지 않았다. 또한 Recall@k, MRR, citation accuracy 같은 RAG 품질 지표는 메모리 벤치마크와 별도로 측정된 자료가 많아, 메모리 절약형 DB가 품질 저하 없이 그 메모리를 아끼는지는 이번 자료만으로 단정할 수 없다. 다음 실험에서는 동일 문서셋으로 384·768·1,024차원을 직접 색인해 피크 RSS와 Recall@10을 같이 기록하는 쪽이 더 재현 가능한 근거가 될 것이다.