읽기 축만 놓고 보면 벡터 677만 개에서 인건비 0에도 자체 운영이 진다

벡터 DB를 자체 운영할지 정하기 전에 낼 값은 자기 벡터 수와 복제 계수, 피크 질의량, 매니지드에 낼 쓰기 물량, 벤더 견적에서 받는 전용 노드 월 요율, 그리고 매니지드 전용 부가 요금이다. 이 글의 기준선에서 그것을 넣으면 허용 인건비가 나온다. 벡터 DB에 붙일 월 인건비가 그 액수를 넘으면 자체 운영이 전용 노드보다 비싸다.

제목의 677만은 그 허용 인건비가 음수로 떨어지는 자리를 위로 올려 잡은 값이고, 정확히는 벡터 6,764,154개까지가 양수다. 아래 세울 전제 안에서는 복제 1·2·3이 전부 같은 자리다. 이 0점은 GB가 아니라 벡터 수에 붙고, 그 전제 안에서 자리를 정하는 것은 벡터당 램이다.

그 아래라고 자체 운영이 자동으로 이기지도 않는다. 종량 요금제와 전용 노드가 갈리는 자리를 첫 게이트, 전용 노드와 자체 운영이 갈리는 자리를 두 번째 게이트라 부른다. 이 글은 둘을 각각 식으로 닫고, 식에 넣을 값을 벤더 가격표와 자기 클라우드 청구서에서 읽는 방법을 준다.

이 글의 계산은 하나의 전제 묶음 위에 선다. 아래에서 그것을 이 글의 기준선이라 부른다. 네임스페이스가 하나여서 질의가 코퍼스 전체를 노리고, 읽기 축만 잰다. 레코드는 8,192 B이고 그중 1,536차원 float32 벡터만 m = 16으로 램에 상주하며 ID와 메타데이터 2,048 B는 디스크에 둔다. 갱신이 없어 W = 0이고 부가 요금을 안 사서 A = 0이다.

요금제는 Pinecone Standard이고 전용 노드 월 요율은 b1 문서 예시값 P = $336.42, 사는 노드 수는 b1 한 대가 자기 몫의 피크를 받는다고 보고 k × r대, 인스턴스는 r7i·gp3다. 그리고 피크 질의가 낮아 vCPU를 선반이 정한다(아래 자체 운영 월액 식의 max가 선반 쪽을 집는다). 전부 아래 계산의 전제이지 일반 사실이 아니다.

0점을 움직이는 것과 첫 게이트를 움직이는 것이 갈린다. 매니지드 전용 부가 요금은 0점을 뒤로 밀고, payload를 램에 캐시하면 앞으로 당기며, 쓰기 물량은 0점을 하나로 남기지 않고, 인스턴스를 바꾸면 계단이 통째로 옮겨간다.

반대로 질의가 코퍼스보다 작은 네임스페이스만 노리거나 요금제를 Enterprise로 올리면 종량 쪽 단가만 바뀌어 첫 게이트가 움직이고 0점은 제자리다. 어느 쪽으로 얼마나 움직이는지는 감도표와 뺀 항목 표에 적었다.

레코드 구성과 네임스페이스 분할은 뺀 항목 표에, 인스턴스와 ID·메타데이터 크기는 감도표에 적었다. 요금제는 종량 월액의 단가를 갈아 끼우고, 쓰기 물량은 식 표의 W가, 매니지드 전용 부가 요금은 A가 받는다. 피크는 자체 운영 vCPU 식의 max가 받는다. 네임스페이스 분할은 아래 식들이 받지 않으니, 나눌 수 있는 조직은 식이 낸 값에 그 축을 직접 얹어야 한다.

종량 계약만 출고비를 창고 평수와 출고 횟수의 곱으로 매긴다

과금 규칙부터 원문 그대로 본다. Pinecone 비용 문서는 질의 요금을 이렇게 정의한다. “Specifically, a query uses 1 RU for every 1 GB of namespace size, with a minimum of 0.25 RUs per query.” 같은 문서가 top_k나 응답 크기는 요금과 무관하다고 못 박는다. “only the size of the namespace determines the number of RUs used.”

세 계약서를 나란히 놓으면 이렇다.

계약	읽기 요금이 비례하는 것	저장	읽기 상한	사람 손
종량 (on-demand)	네임스페이스 GB × 질의 수	$0.33/GB/월	기본 2,000 RU/초	없음
전용 노드	노드 수 (샤드 × 레플리카)	$0.33/GB/월	없음 (CPU 용량까지)	샤드·레플리카 수 결정
자체 운영	아무것도 (선반 값에 포함)	인스턴스·EBS에 포함	없음 (CPU 용량까지)	월 인건비 전부

출처는 Pinecone 가격표와 전용 노드 문서(둘 다 2026-08-29 조회)다. 세 행 중 읽기 요금이 사용량을 따라 자라는 것은 첫 행뿐이고, 나머지 둘은 용량을 사 두는 계약이다.

읽기 단가를 월 단위로 옮긴다. 이 글은 전부 월 730시간으로 계산한다. AWS 관례이고, Pinecone 문서의 전용 노드 월 요율도 같은 값을 쓴다($336.42 ÷ 730 = $0.4608, 문서 표기 $0.46/시간).

항목	값	근거
월 초	2,628,000	730 × 3,600
질의 1건이 쓰는 RU	네임스페이스 GB와 같은 수 (최소 0.25)	Pinecone 비용 문서
RU 단가 (Standard)	$16~$18 / 100만	가격표. “varies by cloud and region”
WU 단가 (Standard)	$4~$4.50 / 100만	같은 출처. 식 표의 W가 쓴다
최소 사용액 (Standard)	$50 / 월	가격표. Enterprise는 $500이라 티어를 밝혀야 한다
읽기 요금 (하단)	$42.048 / (GB × QPS) / 월	2,628,000 × $16 ÷ 10⁶
읽기 요금 (상단)	$47.304 / (GB × QPS) / 월	2,628,000 × $18 ÷ 10⁶

이 글은 하단 $16을 쓴다. 하단은 종량제에 유리한 쪽이므로 “자체 운영이 싸다”는 결론에 보수적이다. 상단을 쓰면 첫 게이트가 종량제에 더 불리해진다. 두 번째 게이트에는 RU 단가가 안 들어간다.

Q는 월 평균 질의량이다. 요금은 월 총 질의 수로 매겨지므로 피크를 넣으면 종량이 부풀어 판단이 자체 운영 쪽으로 기운다. 한도와 사이징을 재는 두 자리에서만 피크를 쓴다.

읽기 요금은 코퍼스 크기와 질의 수의 곱이다. 질의를 안 늘려도 코퍼스가 자라면 오르고, 코퍼스를 안 늘려도 질의가 늘면 오른다. 곱이 합보다 빨리 자라므로 이 요금제를 벗어나는 지점이 반드시 생긴다.

최소 0.25 RU는 네임스페이스가 0.25 GB 아래일 때, 곧 벡터 30,518개 미만일 때만 바닥을 친다. 종량 월액 식에 max(S, 0.25)가 들어가는 이유다. 등가점과 한도 양쪽에 같이 들어가므로 아래 0.40%는 그대로다.

전용 노드가 종량을 이기는 지점은 허용 출고량의 0.40% × 샤드 × 복제다

전용 노드는 창고 한 동을 시간당 요율로 통째로 빌리는 계약이다. Pinecone 문서는 b1 노드를 이렇게 예시한다. “If the rate for b1 nodes on aws-us-east-1 is $336.42/month ($0.46/hour)”. 조건절로 쓰인 문서의 예시 요율이고 가격표에 실린 확정 요율이 아니다.

이 절이 내는 등가점과 비율만 이 요율에 정비례한다. 뒤에 나오는 허용 인건비와 그 상한은 정비례가 아니다. 자기 견적이 이 요율과 다르면 허용 인건비가 그 차액에 샤드 수와 복제 계수를 곱한 만큼 통째로 올라가거나 내려간다.

상한은 다르다. 상한이 서는 자리는 어느 복제에서도 k = 1이라 복제 계수만 곱하고, 그것도 그 자리가 그대로일 때만이다. 자리가 옮겨가는 요율은 복제 1에서 약 3.57배, 복제 2에서 약 3.69배, 복제 3에서 약 3.73배다. 자기 복제 계수의 그 배수를 넘는 견적은 허용 인건비 식에 자기 요율을 넣어 다시 낸다. 요율이 다르면 0점도 옮겨가는데, 0점은 계단이라 닫힌 형이 없다.

문서는 자원이 약 4배이고 값이 약 3배인 t1 노드도 적는데, 이 글은 b1 하나로만 계산했다. P가 3배가 되므로 t1로 읽으면 이 절의 비율이 전부 3배로 옮겨간다(20노드 문턱이 8.0%가 아니라 24.0%다). 자원당 단가는 t1이 싸지만 샤드당 250 GB가 노드 타입과 무관한지는 문서가 밝히지 않아 0점의 k를 다시 낼 수 없었다. 저장 용량은 샤드 하나가 250 GB이고, 샤드 수 k는 올림(S ÷ 250)으로 나온다.

종량 읽기 요금이 노드 값과 같아지는 지점은 곱 하나로 닫힌다.

RU 단가	등가점 S × Q	종량 기본 한도 대비
하단 $16 / 100만	8.000856 × k × r GB·QPS	0.4000428% × k × r
상단 $18 / 100만	7.111872 × k × r GB·QPS	0.3555936% × k × r

오른쪽 열이 이 절의 결론이다. 넘었을 때 버는 액수는 종량 읽기 요금 − P k r이라, 이용률이 문턱의 두 배면 P k r만큼, 예시 B처럼 30.7배면 월 $19,994.59를 번다.

종량 인덱스에는 기본 한도가 있다. “On-demand indexes are subject to read unit rate limits (default: 2,000 RUs/second per index).” 네임스페이스가 S GB면 질의 1건이 S RU를 쓰므로 도달 가능한 최대 QPS는 2,000 ÷ S이고, 등가점은 8.000856 k r ÷ S다. 비를 내면 S가 약분되어 사라진다.

0.40%라는 숫자 자체는 이 글이 쓴 요율($336.42)에서만 나온다. 다른 견적을 받았으면 비율을 P × k × r ÷ 84,096으로 다시 내면 된다(84,096 = $42.048 × 2,000). 2,000 RU/초도 문서에 default라고 적혀 있어 상향 조정이 가능하다. 한도를 두 배로 받아 내면 비율이 절반이 되어 종량이 손해인 구간이 오히려 넓어진다.

직접 지은 창고는 선반을 계단으로 산다

자체 운영은 오픈소스 엔진을 인스턴스에 올린다. 이 글은 Qdrant를 쓴다. Apache License 2.0이라 라이선스 비용이 0이고, 사이징 공식과 처리량 원자료를 둘 다 공개한다.

선반 길이는 Qdrant 용량 계획 문서의 식으로 낸다(2026-08-29 조회).

base           = 포인트 수 × 복제 계수
dense_size     = base × 차원 × 4 B                   (float32)
hnsw_size      = base × m × 2 × 4 B × 1.2            (기본 m = 16)
id_tracker     = base × 52 B
disk(payload)  = base × 평균 payload 크기 × 1.5
ram(payload)   = base × 평균 payload 크기 × 1.5 × 3   (캐시할 때)
여유            = 최종 RAM·디스크에 약 20%

이 글은 payload를 디스크에만 두고 램 캐시는 끄는 구성으로 계산한다. ram(payload) 줄을 켜면 벡터당 램이 2.451배가 된다. 뺀 항목 표에 있다. 아래에서는 base의 복제 계수를 빼고 복제본 하나 기준으로 선반을 낸 다음 인스턴스를 복제 수만큼 산다. 총 선반은 같고 계단이 어디서 생기는지가 보인다.

두 방식이 사는 vCPU는 같지 않다. 500만 벡터·복제 2는 복제본마다 올려 12 vCPU라 인프라비가 $587.95인데, base에 복제 계수를 넣고 한 번만 올리면 10 vCPU라 $491.38이다. 이 글은 물리적으로 사야 하는 앞의 것으로 낸다.

문서의 워크드 예시(100만 포인트, 768차원, 복제 2)를 이 식으로 재현하면 RAM 7.3260 GiB, 디스크 10.7592 GiB가 나온다. 문서가 적은 값은 7.33과 10.76이다. 재현이 소수 둘째 자리까지 맞으므로 이 식을 그대로 쓴다.

문서가 “GB”라고 쓴 단위는 GiB(2진)다. 2,000,000 × 768 × 4는 6.144×10⁹ 바이트인데 문서는 5.72라고 적고, 2³⁰으로 나눠야 나오는 값이다. 디스크 예시는 평균 payload를 1,024 B로 잡았을 때만 맞는다(8.97 − 6.105 = 2.865 GiB이고 2,000,000 × 1,024 × 1.5 ÷ 2³⁰ = 2.8610이다). 벤더 가격표의 GB는 10진이고 엔진 문서의 GB는 2진이라 두 값을 한 계산에 섞으면 7.4% 어긋난다.

1,536차원 기준으로 벡터 하나가 선반 (6,144 + 153.6 + 52) × 1.2 = 7,619.52 B와 디스크 (6,144 + 153.6 + 52 + 2,048 × 1.5) × 1.2 = 11,305.92 B를 쓴다.

인스턴스는 메모리 최적화 r7i를 쓴다. AWS 요금 피드에서 us-east-1 온디맨드 값을 받았다(피드 게시일 2026-08-29). 아홉 개 사이즈 전부가 정확히 $0.06615 / vCPU / 시간이고 메모리는 전부 8 GiB / vCPU다.

2·4·8·16·32·48·64·96·192 vCPU를 조합하면 2 이상의 모든 짝수 vCPU를 만들 수 있고 어떤 조합이든 값이 같다. 그래서 자체 운영 인스턴스비는 조합과 무관하게 vCPU = 2 × 올림(필요 램 GiB ÷ 16) 하나로 닫힌다.

vCPU	$/월 (730h)	담기는 벡터 (1,536차원)	질의 용량 (초당)	조합 예
2	$96.58	2,254,718	315.13	r7i.large
4	$193.16	4,509,436	630.27	r7i.xlarge
6	$289.74	6,764,154	945.40	large × 3
8	$386.32	9,018,872	1,260.53	r7i.2xlarge
72	$3,476.84	81,169,849	11,344.77	8xlarge × 2 + 2xlarge

두 열이 나란히 자라므로 이 표만으로는 무엇이 먼저 차는지 안 나온다. 정하는 것은 조직의 질의량 대 벡터 수 비다.

질의 용량 열은 Qdrant 벤치마크 원자료의 값에서 왔다. 100만 벡터 × 1,536차원(dbpedia-openai-1M-1536-angular)을 8 vCPU / 32 GiB 서버(Azure Standard D8s v3)에 올리고 병렬 클라이언트 100개로 때렸을 때 초당 1,260.53건, p95 5.22 ms, 정밀도 0.9666이다(행 이름 qdrant-rps-m-16-ef-128, hnsw_ef = 64, 양자화 없음, 전 엔진 메모리 25 GB 상한).

같은 파일의 qdrant-m-16-ef-128은 파라미터가 같은데 초당 612.54건이라 2.06배 갈리므로 행 이름까지 적어야 대조가 닫힌다.

vCPU당 157.56625건으로 나눠 썼다. 이것은 측정값이 아니라 가정이다. 원자료는 8 vCPU 한 점이고 이 글은 그것을 2에서 72 vCPU까지 선형으로 늘려 쓴다. 벡터 밀도도 함께 바뀌는데(측정은 vCPU당 0.89 GiB, 이 글의 72 vCPU 구성은 vCPU당 7.9 GiB) 원자료가 그 축을 분리해 주지 않는다. 아래 질의 용량 열은 그 가정 위의 값이다.

디스크는 EBS gp3로 잡았다. AWS EBS 요금 페이지가 “a region that charges $0.08 per GB-month” 형식으로 제시하고 리전을 밝히지 않는다. 자체 운영 인프라비의 2% 안쪽이라 이 값을 두 배로 틀려도 총액이 2% 안에서 움직인다.

여기서 계단이 생긴다. vCPU는 2개 단위로만 살 수 있고 EBS는 1 GiB 단위로만 살 수 있다. 네임스페이스 1 GB당 값을 연속으로 내면 이렇다.

항목	값	산식
네임스페이스 1 GB의 벡터 수	122,070.3125	10⁹ ÷ 8,192
선반	0.866239 GiB	122,070.3125 × 7,619.52 ÷ 2³⁰
vCPU (쪼개 쓸 수 있다면)	0.108280	0.866239 ÷ 8
인스턴스	$5.228782 / 월	0.108280 × $48.2895
디스크	1.285334 GiB → $0.102827 / 월	payload 포함, × $0.08. EBS는 GiB로 프로비저닝·과금되므로 이 행만 2진 수량에 벤더 요율을 곱한다
R (연속 하한)	$5.331609 / (네임스페이스 GB) / 월	위 둘의 합

R은 하한이다. vCPU를 0.108280개 살 수는 없으므로 실제 청구서는 언제나 이보다 크다. 얼마나 큰지는 적재율(선반 GiB ÷ 실제로 산 램 GiB)이 정하고, 적재율은 코퍼스가 커진다고 좋아지지 않는다. 계단을 갓 넘으면 최악이다. 아래 표와 예시는 전부 실제로 사는 정수 인스턴스로 계산한다.

두 번째 게이트는 창고지기 급여 하나로 닫힌다

종량 계약과 직접 짓기를 나란히 세운다. 자체 운영이 종량보다 싸지는 질의량을 창고지기 급여 0, 복제 하나에서 내면 이렇다.

벡터 수	S (GB)	적재율	인프라비 (복제 1)	종량 등가 Q*	종량 등가 하한 대비
30만	2.458	13.3%	$96.90	0.929849	7.82배
100만	8.192	44.4%	$97.46	0.275087	2.31배
200만	16.384	88.7%	$98.34	0.134897	1.13배
500만	40.960	73.9%	$293.98	0.162842	1.37배
1,000만	81.920	88.7%	$491.38	0.134804	1.13배
1억	819.200	98.6%	$4,430.30	0.120769	1.02배

연속 하한 R이 내는 종량 등가는 (R − $0.33) ÷ $42.048 = 초당 0.118950건이고, 이것을 종량 등가 하한이라 부른다. 표의 어느 행도 그 값이 아니고 전부 그 위다. 그리고 단조롭게 내려오지 않는다. 200만에서 1.13배까지 내려왔다가 500만에서 1.37배로 되올라간다. 500만 벡터가 6 vCPU 계단을 갓 넘어 적재율이 73.9%로 떨어지기 때문이다. 30만 벡터 조직이 하한을 믿고 초당 0.2건에서 자체 운영으로 가면 급여 0에서도 종량 등가가 0.93건이라 손해다.

전용 노드와 자체 운영을 직접 세우면 평균 질의량이 사라진다. 둘 다 용량을 사 두는 계약이라 몇 번 꺼내든 값이 같기 때문이다. 남는 것은 선반과 창고지기 급여, 자체 운영에만 없는 동 월세·보관료·입고비, 그리고 매니지드 전용 부가 요금이다. 피크는 선반을 제치고 vCPU를 정하는 구간에서만 자체 운영 인프라비를 올려 허용 인건비를 낮춘다.

k = 1, P = $336.42로 코퍼스별 L을 낸다. 자체 운영 인프라비는 정수 vCPU와 정수 EBS로 냈고, 피크가 낮아 선반이 vCPU를 정하는 구간의 값이다. 피크가 vCPU를 정하면 L이 그만큼 내려간다(벡터 200만·복제 2에서 피크 초당 1,200건이면 $481.57이 $288.41이다).

벡터 수	S (GB)	선반/노드	vCPU	인프라비 (복제 1)	허용 L (복제 1)	인프라비 (복제 2)	허용 L (복제 2)
30만	2.458	2.13 GiB	2	$96.90	$240.33	$193.80	$479.85
100만	8.192	7.10 GiB	2	$97.46	$241.66	$194.92	$480.63
200만	16.384	14.19 GiB	2	$98.34	$243.49	$196.68	$481.57
500만	40.960	35.48 GiB	6	$293.98	$55.96	$587.95	$98.40
6,764,154	55.412	48.00 GiB (미달)	6	$295.50	$59.21	$590.99	$100.13
6,764,155	55.412	48.00 GiB (초과)	8	$392.08	−$37.37	$784.15	−$93.03
900만	73.728	63.87 GiB	8	$393.92	−$33.17	$787.83	−$90.66

벡터 6,764,154개와 6,764,155개 사이가 이 글의 답이다. 벡터 하나가 늘어 선반이 48 GiB를 넘는 순간 vCPU를 2개 더 사야 하고, 그 $96.58이 허용 인건비를 음수로 밀어 넣는다. 그 위로는 이 글의 기준선 안에서 다시 양수가 되지 않는다.

복제 1·2의 상한은 이 글의 기준선에서 선반 계단 꼭대기인 벡터 2,254,718개에서 $244.02와 $481.94다. 복제 3은 그보다 앞선 2,184,347개에서 $719.91인데, 디스크가 23 GiB를 갓 안 넘어 EBS가 1 GiB 덜 붙는 자리이기 때문이다. 복제가 늘수록 그 1 GiB 값도 복제 수만큼 커져서 상한 자리가 옮겨간다.

이 상한은 전용 노드 월 요율 P에 정비례하지 않는다. 견적이 1.5배($504.63)면 복제 2 상한이 $722.91이 아니라 $818.36이고, t1 요율($1,009.26)이면 $1,445.81이 아니라 $1,827.62다. 상한이 서는 첫 계단은 코퍼스 18.47 GB 안이라 어느 노드 타입에서도 k = 1이고, 요율을 갈아 끼운 상한도 샤드 불확실성 없이 나온다.

이 상한은 쓰기 요금과 부가 요금을 뺀, 곧 W = 0·A = 0에서 잰 값이다. A는 코퍼스와 무관하므로 상한이 A만큼 그대로 올라간다. W는 벡터 수에 비례해서 다르다. 갱신률이 오르면 상한 자리가 먼저 옮겨가고, 더 오르면 코퍼스가 커질수록 L이 올라가 상한이 아예 없어진다. 그러니 갱신이 있는 조직의 상한은 그 복제별 세 값이 아니고, 허용 인건비 식에 자기 W를 넣어 자기 코퍼스에서 다시 내야 한다.

아래는 매일 1% 갱신에서 낸 값이다. 복제 2 상한이 $526.88이라 월 1인일을 붙이는 조직의 답이 벡터 약 97만 5천 개부터 첫 계단 꼭대기 2,254,718개까지 자체 운영으로 뒤집힌다. HIPAA 애드온까지 사면 그 조직의 복제 2 상한이 $716.88(약 1.43인일)이 되어, 월 1인일을 붙이는 답이 벡터 4,509,436개까지 자체 운영으로 뒤집힌다(뺀 항목 표).

피크가 낮아 선반이 vCPU를 정하는 구간에서는, 복제 하나를 더하면 허용 인건비가 P k에서 복제본 하나의 인프라비를 뺀 만큼 는다. 앞 표는 k = 1이라 두 L 열의 차가 각 행에서 그 값이고, 8 vCPU 계단의 두 행에서는 음수라 복제를 늘리면 오히려 줄어든다.

복제 3은 같은 구간에서 복제 2에 그 증분을 한 번 더 더한 자리다. 그런데 허용 인건비가 0을 지나는 벡터 수는 이 글의 기준선에서 복제 1·2·3에 전부 6,764,154개로 같다. 그 기준선 안에서 부호를 뒤집는 것이 복제가 아니라 선반 계단이라서다.

자체 운영과 전용 노드는 인건비가 가르고, 살아남은 쪽과 종량은 질의량이 가른다

세 조직 모두 1,536차원, ID와 메타데이터 2,048 B, 레코드 8,192 B이고 갱신이 없어 W = 0, 부가 요금을 안 사서 A = 0이다. 요금은 월 평균 질의량으로 매기고 한도와 사이징은 피크로 잰다. 종량 한도는 순간 RU/초에 걸리므로 평균으로 재면 스로틀 구간을 놓친다. 피크는 클라우드 콘솔의 초 단위 최대 요청 수(p100)로 읽는다.

질의량으로 줄을 세우면 0.05 → 종량, 2 → 전용 노드, 30 → 자체 운영으로 단조로워 보이지만 세 예시의 우연이다. 못 사는 것을 뺀 뒤 답은 두 번에 걸쳐 갈린다. 두 번째 게이트가 먼저 열려 자체 운영과 전용 노드 중 하나를 떨어뜨리고, 살아남은 쪽이 종량과 겨룬다. 게이트 번호는 이 글이 잰 순서이고 답이 갈리는 순서는 그 반대다.

두 번째 게이트를 정하는 것은 월 인건비와 허용 인건비 L의 비교다. 평균 질의량은 여기 안 들어가고, 피크는 선반을 제치고 vCPU를 정하는 구간에서만 L을 통해 들어온다. L이 음수면 인건비를 0으로 놓아도 자체 운영이 먼저 떨어진다.

남은 비교를 정하는 것은 평균 질의량인데, 문턱은 살아남은 쪽에 따라 다르다. 전용 노드가 살아남았으면 첫 게이트의 0.40% × k × r이다. 자체 운영이 살아남았으면 자체 운영 월액과 종량 월액이 같아지는 질의량이고, 식 표의 두 월액을 같게 놓고 자기 값으로 풀어야 한다.

다만 종량 월액은 최소 사용액을 못 채우는 구간에서 Q와 무관하게 평탄하므로, 푼 값이 그 구간에 떨어지면 근이 아니다. 그때는 평탄한 종량 월액과 자체 운영 월액을 그냥 비교한다.

월 인건비와 쓰기 요금 W, 부가 요금 A가 전부 그 자리에 들어가므로 앞 표의 종량 등가 Q*를 그대로 쓸 수 없다. 그 표는 급여 0·복제 하나·W = 0·A = 0의 값이다. 인건비만 얹으면 문턱이 오른쪽으로 밀리고, 인건비가 L에 닿으면 첫 게이트 자리까지 간다(200만·이중화에서 0.278이 0.977로).

예시 C는 두 번째 게이트에서 떨어져 질의량을 열 배로 올려도 답이 전용 노드다. 허용 인건비가 −$4,853.78이라 계단이 이미 자체 운영을 뺐기 때문이다. 예시 A와 B는 반대로 둘 다 첫 계단 안 (2 vCPU)이라 허용 인건비가 +$240.33과 +$481.57로 나란히 양수인데, 답이 종량과 자체 운영으로 갈렸다. 남은 비교에서 질의량이 초당 0.05건과 30건으로 갈렸기 때문이고, A가 자체 운영으로 넘어오는 자리는 창고지기 급여 0에서 종량 등가 0.929849건이다.

세 선택지의 월액과 허용 인건비는 식으로 나오고, 0점은 GB가 아니라 벡터에 붙는다

예시 셋이 끝까지 시연한 계산을 식으로 모으면 이렇다. 자기 청구서와 가격표에서 값을 읽어 넣으면 세 선택지의 월액과 허용 인건비가 나온다.

값	식
S (네임스페이스 GB)	레코드 수 × 레코드 크기 B ÷ 10⁹. 레코드 크기 B = ID와 메타데이터의 합 + 차원 × 4 B이고 이 글에서 8,192다
샤드 수 k	올림(S ÷ 250)
종량 월액	max(최소 사용액, (2,628,000 × RU 단가 ÷ 10⁶) × max(S, 0.25) × 평균 Q + s S + W) + A. 이 글의 RU $16에서 계수가 $42.048이다. A를 max 밖에 둔 것은 애드온이 사용량이 아니라 구독이라서인데, 최소 사용액이 애드온을 흡수하는지는 가격표가 밝히지 않는다. 흡수한다면 종량이 부가 요금만큼 싸지고, 사용량이 예시 A 수준인 월 $5.98이면 $44.02에서 멈춘다. 평균 Q(초당) = 월 총 질의 수 ÷ 2,628,000
전용 노드 월액	P k r + s S + W + A. A는 매니지드 전용 부가 요금(HIPAA 월 $190, 지원 Developer 월 $29·Pro 월 $250)이고 종량 월액에도 같이 붙는다. b1 한 대의 질의 용량을 견적으로 받기 전에는 이 값이 하한이다
선반 GiB, 디스크 GiB	레코드 수 × 벡터당 램 B ÷ 2³⁰, 레코드 수 × 벡터당 디스크 B ÷ 2³⁰. S의 10⁹과 섞으면 7.4% 어긋난다
자체 운영 월액	자체 운영 인프라비 = r × (vCPU × vCPU 월 요율 + 올림(디스크 GiB) × EBS 단가). 자체 운영 월액 = 인프라비 + 월 인건비. vCPU = 2 × 올림(max(선반 GiB ÷ 16, 피크 Q ÷ r ÷ (vCPU당 초당 처리량 × 2))). 이 글은 처리량이 157.56625건이라 뒤 항의 분모가 315.13이다. 이 식은 r벌이 다 살아 있다고 보고 재므로, 한 대가 죽어도 피크를 받아야 하면 분모의 r을 r − 1로 바꾼다(복제 1은 그 요건을 복제로 못 받는다). 피크가 vCPU를 정하는 구간에서는 그 교체가 부호를 뒤집는다(벡터 200만·복제 2·피크 초당 1,200건에서 L이 +$288.41에서 −$97.91로 간다)
매니지드 쓰기 월액 W	월 갱신 레코드 수 × 레코드 KB × 2 × WU 단가. 레코드 KB는 10진(레코드 B ÷ 1,000)이고, ×2는 기존 레코드를 덮어쓸 때 문서가 “uses 1 WU for each 1 KB of the existing record as well”로 기존분을 한 번 더 매기기 때문이다. 월 갱신 레코드 수 = 벡터 수 × 일 갱신률 × 30.4167(730시간 ÷ 24). 종량과 전용 노드에 같이 붙고 자체 운영은 0이다
허용 인건비 L	전용 노드 월액 − 자체 운영 인프라비 = P k r + W + A − (자체 운영 인프라비 − s S). 갱신이 없으면 W = 0, 부가 요금을 안 사면 A = 0이다. 벡터 6,764,155개·복제 1·인건비 0인 조직은 A = 0에서 −$37.37이라 전용 노드지만 HIPAA와 Pro 지원을 사면 A = $440으로 +$402.63이라 자체 운영이다

이 표에서 조직마다 다른 것은 레코드 수·복제 계수·평균 Q·피크 Q·갱신률·월 인건비, 그리고 자기 견적에서 받는 전용 노드 월 요율 P와 자기가 사는 부가 요금 A다. 나머지는 가격표와 자기 인스턴스에서 그대로 읽는다. P를 가격표 값으로 고정하지 않는다. 이 글의 $336.42는 문서의 예시 요율이다.

먼저 못 쓰는 것을 뺀다. 피크 Q ÷ (2,000 ÷ max(S, 0.25))가 100%를 넘고 한도 상향을 못 받으면 종량이 빠진다. k가 20을 넘으면(코퍼스 5,000 GB 초과) 어떤 r로도 전용 노드를 못 산다. k는 20 이하인데 k × r이 20을 넘으면 r을 20 ÷ k 이하로 낮춰야 살 수 있고, 그때 포기하는 것이 복제다. 낮춘 r로 세 선택지의 월액을 다시 내서 그 구성과 원래 구성을 나란히 놓는다.

남은 것 중 가장 싼 것을 고른다. 월 인건비는 월 투입 인일 × 인일 단가로 내고 당직·버전 업그레이드·장애 대응·규정 준수 공수를 넣는다. 인일 단가는 부담 연봉 ÷ 연 가동 인일이고 자기 조직 값을 넣는다. 그 값이 L을 넘으면 자체 운영이 전용 노드에 진다. 구축비를 몇 달에 회수하는지는 예시 B가 시연하지만, 이 글에 성장 모델이 없어 코퍼스가 자라는 조직에는 그 개월 수를 주지 않는다.

예시 A는 종량, 예시 B는 자체 운영, 예시 C는 전용 노드로 갈렸다. 셋을 다 내야 하는 이유가 여기 있다. 종량이 전용 노드보다 싸다고 거기서 멈추면 자체 운영이 더 싼 자리를 놓친다. 200만 벡터·이중화·초당 0.5건 조직은 종량 $349.86이 전용 노드 $678.25보다 싸지만 자체 운영 인프라비는 $196.68이라, 월 인건비가 $153.18을 넘지 않으면 자체 운영이 가장 싸다. 이 인건비 문턱은 종량 월액 − 자체 운영 인프라비이므로 쓰기 요금과 부가 요금이 붙으면 그만큼 올라간다.

앞의 이중화한 200만 벡터 그림에서 종량선이 자체 운영선과 전용 노드선 사이를 지나는 초당 0.278~0.977건 구간이 그것이고, 종량이 전용 노드보다 싼 구간의 71.6%가 거기에 걸린다. 이 비율은 (L − 월 인건비) ÷ (P k r)로 나오고, 71.6%는 인건비 0의 값이라 월 $200이면 41.8%로 준다. 500만 벡터·복제 1이면 인건비 0에서 16.6%다.

쓰기 요금이나 부가 요금이 커서 이 비율이 100%를 넘으면 종량이 전용 노드보다 싼 구간 전부가 자체 운영이다(100만 벡터·복제 1·매일 10% 갱신에서 131.1%다).

식에 넣을 파라미터와 단가는 자기 환경에서 읽는다. 이 글의 $48.2895와 $0.08은 r7i·gp3의 값이고, gp3 단가의 리전은 AWS 페이지가 밝히지 않는다. m은 Qdrant 컬렉션의 hnsw_config.m, 평균 ID·메타데이터 크기는 자기 레코드 표본, 월 총 질의 수는 청구서, 피크 Q는 클라우드 콘솔의 초 단위 최대 요청 수(p100)에서 읽는다.

벡터당 램과 디스크는 1,536차원·m = 16·ID와 메타데이터 2,048 B·벡터를 램에 float32로 올릴 때 7,619.52 B와 11,305.92 B이고, 차원·m·ID와 메타데이터를 바꾸면 (차원 × 4 + m × 9.6 + 52) × 1.2와 (차원 × 4 + m × 9.6 + 52 + ID와 메타데이터 B × 1.5) × 1.2로 다시 낸다.

벡터를 램에 float32로 올리지 않는 구성은 이 식으로 못 낸다. 양자화본을 얹거나 벡터를 디스크에 두면 무엇이 램에 남는지가 설정마다 다르고, 이 글은 그 조합을 검증하지 못했다. 그런 구성이면 자기 인스턴스의 RSS ÷ 벡터 수를 재서 벡터당 램 자리에 넣는다. vCPU당 초당 처리량 157.56625건도 그 구성으로 잰 벤치마크 행에서 다시 읽어야 한다. vCPU 식이 램과 질의 중 큰 쪽을 쓰므로, 램만 줄이고 처리량을 그대로 두면 절감이 질의 쪽에 흡수되어 아무것도 사지 못한다.

감도 (R을 바꾸는 것)	R (연속 하한)	종량 등가 하한	허용 인건비 0점
이 글의 기준 (r7i, ID와 메타데이터 2,048 B)	$5.331609	0.118950	55.41 GB (6,764,154개)
ID와 메타데이터 0 (레코드 6,144 B)	$7.064108	0.160153	41.56 GB (6,764,154개)
Graviton3 (r7g, $0.05355/vCPU/시간)	$4.335650	0.095264	73.88 GB (9,018,872개)

ID와 메타데이터를 빼면 GB로는 0점이 25% 앞당겨지는데 벡터로는 한 개도 안 움직인다. 램은 벡터 바이트에만 비례하고 ID와 메타데이터는 디스크로 가므로 선반 계단이 그대로이기 때문이다. 0점은 GB가 아니라 벡터 수에 붙는다.

인스턴스를 Graviton3로 바꾸면 계단을 하나 더 살 수 있어 0점이 벡터로 33% 뒤로 밀린다. r7g 단가도 같은 AWS 요금 피드에서 읽었고(2026-08-29 조회), 처리량 157.56625건은 x86에서 잰 값이라 r7g의 vCPU당 처리량은 확보하지 못했다. 피크가 vCPU를 정하는 구간에서는 이 행을 쓸 수 없다. 세 행 모두 벡터를 램에 float32로 올린 기준이고, 양자화하거나 벡터를 디스크에 둔 구성은 이 표에 없다.

크기까지 낸 것은 부가 요금·payload 캐시·쓰기 요금이고, 쓰기 요금은 0점을 하나로 남기지 않는다

뺀 항목	0점을 어느 쪽으로 미는가	근거와 크기
벡터 on-disk (mmap)	0점을 뒤로. 크기는 처리량이 정한다	벡터 본체를 디스크에 두고 HNSW 그래프와 ID만 램에 올리면 Qdrant 용량 계획 문서의 cold 티어 규약대로 벡터당 램이 (m × 9.6 + 52) × 1.2 = 246.72 B가 된다(2026-08-30 조회). 선반이 30.88배 줄어 예시 C의 허용 인건비가 −$4,853.78에서 +$1,713.59로 뒤집힌다. 다만 그것은 예시 C처럼 선반이 vCPU를 정하는 조직의 값이다. 자체 운영 vCPU 식이 램과 질의 중 큰 쪽을 쓰므로, 질의가 정하는 구간에서는 절감이 통째로 흡수되어 float32와 값이 같다(벡터 100만·복제 2·피크 초당 2,000건에서 양쪽 다 −$98.85). 어디까지 뒤집히는지는 이 구성의 처리량이 정하고, 이 글은 그 값과 p95 지연을 확보하지 못했다. 이 구성은 질의마다 디스크를 읽으므로 gp3 기본 3,000 IOPS·125 MB/s가 먼저 걸릴 수 있고, 초과분은 EBS 요금 페이지의 $0.005/IOPS/월·$0.06/(MB/s)/월이 붙는다(2026-08-29 조회). 그만큼 이 레버의 절감은 위에 적은 것보다 작다
벡터 양자화	방향 불명	양자화본을 램에 올리고 원본을 디스크로 내리면 선반이 줄지만, Qdrant 용량 계획 문서는 “Qdrant stores this compressed copy alongside the original vectors”라고 적고 양자화본의 티어가 원본 티어를 따른다고 한다(2026-08-30 조회). 원본을 램에 둔 채 양자화본을 얹는 설정이면 선반이 오히려 는다. 설정에 따라 방향이 갈리고 이 글은 그 조합을 검증하지 못했다. 이미 양자화를 쓰고 있으면 자기 인스턴스의 RSS ÷ 벡터 수와 그 구성으로 잰 처리량을 자체 운영 vCPU 식에 넣으면 자기 0점이 나온다. 램만 넣고 처리량을 기본값으로 두면 그 식의 max가 질의 쪽을 집어 절감이 사라진다
쓰기 요금	0점이 하나로 안 남는다. 크기는 식 표가 낸다	매니지드 두 선택지가 같은 규칙으로 과금하고 자체 운영만 0이다. 달러로는 0이지만 자체 운영의 색인 연산 부하는 이 글이 재지 않았고(인용한 벤치마크가 검색 전용 행이다) 그만큼 자체 운영을 유리하게 봤다. 예시 B에서 매일 코퍼스 1%를 갱신하면 월 997만 WU = $39.87이고 벡터당 월 $0.00001993이다(자체 운영 인프라비 $196.68의 20.3%). 그 갱신률을 L에 넣으면 부호가 한 번만 바뀌지 않는다. W는 벡터 수에 비례하는데 자체 운영은 계단이라 L이 톱니가 되고, 복제 1에서 마지막 양수 자리가 31,566,052개인데 그 아래 절반이 넘는 구간이 음수다. 갱신이 있는 조직은 0점을 읽지 말고 자기 벡터 수를 식 표에 넣어야 한다. 677만이 단일 경계인 것은 갱신이 없을 때뿐이다
약정·연간 계약 할인	방향 불명	온디맨드 정가로 계산했다. AWS 1차 요금 파일이 435 MB여서 이 글에서 읽지 못했다. AWS 할인만 보면 계단이 낮아져 0점이 뒤로 밀리지만, Pinecone 쪽 연간 계약 할인 요율을 확보하지 못해 방향이 정해지지 않는다. 두 요율을 다 받아야 방향이 나온다
Qdrant payload 램 캐시	0점을 앞으로. 크기가 나온다	이 글은 껐다. 그래서 payload는 디스크에만 남고, 그 조회 지연은 이 글이 재지 않았다. 켜면 벡터당 램이 7,619.52 → 18,678.72 B로 2.451배가 되고 계단 수도 그만큼 는다. 올림이라 배수가 정확히 보존되지는 않는다(예시 C는 36 → 87계단). 0점이 6,764,154 → 2,759,268개(22.60 GB)로 앞당겨지고 복제 1·2·3에서 같다
인스턴스 명목 램과 실사용 가능 램의 차이	0점을 앞으로. 크기는 못 냈다	사이징에 Qdrant 권고 여유 20%가 들어 있으나 EC2 명목 메모리 전부를 쓸 수는 없다. 먼저 걸리는 것은 적재율이 가장 높은 조직이고, 이 글의 0점이 바로 그 자리다. 앞 표대로 선반이 48.00 GiB라 6 vCPU의 램을 꽉 채워 여유가 없다. 예시 셋 중에서는 98.6%인 예시 C가 1.44%만 모자라도 계단을 하나 더 산다(예시 B는 11.30%까지 안 움직인다)
전환·구축 공수	0점 밖	자체 운영 쪽은 예시 B가 회수 개월로 냈다. 전용 노드로 옮기는 공수는 이 글이 재지 않았고, 그만큼 전용 노드를 유리하게 봤다
b1 노드 1개의 질의 용량	방향 불명	문서가 밝히지 않는다. 이 글은 비용 등가점만 냈고 전용 노드의 $/QPS는 내지 않았다. 실제 견적에서 필요한 레플리카 수가 이 글의 가정보다 많으면 자체 운영 쪽으로 움직인다. 크기는 첫 계단 안 허용 인건비 전체를 뒤집을 만하다. 벡터 200만·복제 2·피크 초당 2,000건을 이 글은 2노드 $678.25로 재지만, 견적이 6노드를 요구하면 전용 노드가 $2,023.93이라 자체 운영 $776.15가 월 $1,247.77 싸다
b1과 램 상주 자체 운영의 아키텍처 차이	방향 불명	b1이 벡터 본체를 램에 올리는지 문서가 밝히지 않는다
네임스페이스 분할	0점 밖. 첫 게이트를 종량 쪽으로 크게 민다	Pinecone 비용 문서는 “The cost of a query scales linearly with the size of the targeted namespace”라고 적는다(2026-08-30 조회). 이 글은 네임스페이스가 하나여서 노리는 크기 = 코퍼스로 놓았다. 나눌 수 있으면 종량 읽기 요금이 그 비율만큼 준다. 예시 C가 질의를 200만짜리 hot 네임스페이스로 한정하면 종량이 $55,329.42에서 $1,594.10으로 내려가 전용 노드 $2,234.79보다 싸고, 한도 이용률도 98.30% → 2.46%가 되어 답이 종량으로 뒤집힌다. 그때 포기하는 것은 검색 범위다. 예시 C는 8,000만 중 7,800만(97.5%)을 질의가 못 보게 되므로 이것은 요금 레버가 아니라 제품 동작 변경이고, hot 밖을 찾아야 하는 질의가 있으면 쓸 수 없다. 전용 노드는 문서상 네임스페이스 하나만 쓰므로 이 레버가 없다
전용 노드 노드 수 상한	0점 밖. k > 20이면 후보에서 빼고, 그 아래면 r을 깎아야 산다	전용 노드 문서가 프로젝트당 20개를 상한으로 적는다(2026-08-29 조회). k가 20을 넘으면(코퍼스 5,000 GB 초과) 어떤 r로도 못 사고, 그 아래에서 k × r이 20을 넘으면 r을 20 ÷ k 이하로 깎아야 산다. 복제를 유지한 채 살 수 있는 코퍼스는 복제 1에서 5,000 GB, 복제 2에서 2,500 GB, 복제 3에서 1,500 GB까지다
종량 한도 상향	0점 밖	첫 게이트(종량 대 전용 노드)만 움직인다. 2,000 RU/초는 기본값이고 올리면 등가점 비율이 그만큼 작아진다
코퍼스·질의 성장	0점 밖. 답이 바뀌는 달을 정한다	이 글의 식들은 오늘 값을 낸다. 선반 계단·샤드 경계·종량 한도·20노드 상한이 차례로 걸리고, 종량 월액은 S에 정비례해 계단인 자체 운영을 연속으로 지나간다. 언제 지나는지는 월 증가분이 정하고 이 글은 그것을 재지 않았다
관리형 오픈소스	0점 밖. 네 번째 후보를 연다	이 글은 Pinecone 두 요금제와 자체 운영만 비교했고, 같은 Apache 2.0 엔진을 파는 관리형 요금을 1차 출처로 확보하지 못했다. 인건비가 L을 넘는 조직은 이 후보를 따로 견적받아야 한다
이그레스	0점 밖. 대칭	AWS와 Pinecone 둘 다 월 100 GB가 무료다. Pinecone 가격표의 초과 요율은 $0.10/GB다(2026-08-29 조회). AWS 쪽 초과 요율은 확보하지 못했고, 그만큼 대칭 판정이 반쪽이다
매니지드 전용 부가 요금 (규정 준수·지원)	0점을 뒤로. 크기가 나온다	Pinecone 가격표가 HIPAA 애드온 월 $190, 지원 애드온 Developer 월 $29·Pro 월 $250을 Standard에 적는다(2026-08-29 조회). 종량과 전용 노드 양쪽에만 붙으므로 허용 인건비 L이 그만큼 늘고 0점이 뒤로 밀린다. HIPAA면 복제 1에서 6,764,154 → 11,273,590개·복제 2·3에서 9,018,872개, Pro 지원이면 복제 1에서 13,528,308개·복제 2·3에서 9,018,872개, 둘 다면 복제 1에서 18,037,744개·복제 2·3에서 11,273,590개다. HIPAA만으로도 벡터 6,764,155개·복제 2에서 L이 −$93.03에서 +$96.97로 뒤집히고 상한이 $481.94에서 $671.94가 된다. 자체 운영은 이 항목이 인건비로 들어오므로 그쪽을 얼마로 잡느냐가 방향을 되돌릴 수 있다

행은 이렇게 갈린다. 0점을 뒤로 미는 것(벡터 on-disk·매니지드 전용 부가 요금), 앞으로 당기는 것(payload 램 캐시·명목 램 차이), 0점을 단일 경계로 안 남기는 것(쓰기 요금), 방향이 안 정해진 것(양자화·약정 할인·b1 질의 용량·b1 아키텍처)과 0점 밖에서 움직이는 것이다.

크기까지 나온 것은 매니지드 전용 부가 요금·payload 램 캐시·쓰기 요금이다. 매니지드 전용 부가 요금이 복제 1의 0점을 HIPAA에서 1,127만·Pro 지원에서 1,353만으로 밀고, payload 램 캐시가 276만으로 당긴다. 쓰기 요금은 크기가 나오지만 0점을 한 자리로 옮기는 것이 아니라 L을 톱니로 만든다. 약정 할인은 양쪽 요율을 다 확보하지 못해 방향조차 못 냈고, 명목 램 차이는 인스턴스마다 달라 방향만, 벡터 on-disk는 그 구성의 처리량이 없어 방향만 나온다.

그래서 6,764,154개는 이 글의 결론이 아니라 이 글이 계산한 구성의 결론이다. 기준선의 전제 가운데 하나라도 벗어나면 0점이나 첫 게이트가 옮겨간다. 자기 구성의 벡터당 램과 처리량을 자체 운영 vCPU 식에 넣으면 자기 코퍼스에서의 허용 인건비 부호가 나온다.

1편이 고정비와 종량의 교차로 세운 구조를 이 글은 벡터 DB로 옮겼다. 다른 점이 하나 있다. 1편에서는 고정비가 상수였는데 여기서는 자체 운영비가 코퍼스를 계단으로 따라가서, 부호를 뒤집는 것이 코퍼스 크기 자체가 아니라 계단을 넘는 순간이다.

4편은 같은 코퍼스의 색인 비용을 다뤘다. 4편이 쓰기 요금을 재고 조회 요금을 남겨 두었고, 이 글이 그 조회 요금을 잰다. 레코드 8,192 B와 10진 GB 규약을 4편에서 그대로 이어받았다.

이 글의 두 갈림은 Pinecone 가격표와 AWS 요금 피드 위에 서 있다. 값이 바뀌면 8.0 GB·QPS도 6,764,154개도 바뀐다. 바뀌지 않는 것은 구조다. 종량 계약은 출고비를 창고 평수와 출고 횟수의 곱으로 매기고, 나머지 두 계약은 평수로만 매긴다. 곱이 합보다 빨리 자라므로 첫 게이트는 반드시 있고, 그 자리는 허용 출고량에 비해 언제나 낮다.

그 자리가 얼마나 낮은지는 전용 노드가 프로젝트당 20개까지라는 데서 나온다. 문턱 P k r ÷ 84,096은 이 글의 요율에서 0.4000428% × k × r이므로 8.000856%를 못 넘는다. 뒤집으면 평균 이용률이 그 값을 넘고 살 수 있는 구성이라면 전용 노드가 종량을 언제나 이긴다. 자체 운영과의 비교는 별개이고, 예시 B가 이용률 24.576%에서도 자체 운영으로 가는 자리다.

두 번째 게이트는 다르다. 평수로만 매기는 두 계약을 비교하면 평균 출고 횟수가 약분되고 선반과 창고지기 급여, 자체 운영에만 없는 동 월세·보관료·입고비, 그리고 매니지드 전용 부가 요금이 남는다. 6,764,154개 아래에서 자체 운영을 고를지는 그 창고에 사람을 얼마나 붙일 수 있느냐의 문제이고, 이 글의 기준선에서 복제 2 기준 월 $481.94가 그 상한이다.

그 위에서는 선반을 줄이는 수밖에 없고, 선반을 줄이는 레버는 벡터 on-disk 하나다. 양자화는 설정에 따라 선반을 줄이기도 늘리기도 해서 레버로 세울 수 없다. 매니지드 쪽에는 둘 다 없다. 인덱스 크기 식이 차원 × 4 B로 고정이기 때문이다.

on-disk도 크기는 못 냈다. 벡터당 램만 줄이고 처리량을 같이 재지 않으면 절감이 질의 쪽에 흡수되기 때문이고, 그 처리량을 확보하는 것이 이 글이 남기는 숙제다. 677만은 이 글의 기준선을 지키는 조직의 값이고, 그 조직에게는 되돌아오지 않는 자리다.