On the read axis alone, self-hosting a vector DB loses at 6.76 million vectors even at zero labor cost

Before you decide whether to self-host a vector database, collect six numbers: your vector count, your replica factor, your peak query rate, the write volume you would send to the managed service, the monthly per-node rate you get from the vendor’s quote, and the managed-only add-ons you would buy. On this post’s baseline, those six give you an allowable labor budget. If the monthly labor you would attach to the vector database exceeds that figure, self-hosting costs more than dedicated nodes.

The 6.76 million in the title rounds up the point where that allowable budget goes negative; the exact last positive vector count is 6,764,154. Under the premises set out below, replica 1, 2, and 3 all land on the same spot. That zero point attaches to a vector count, not to gigabytes, and within those premises what fixes its position is RAM per vector.

Below it, self-hosting does not automatically win either. Call the place where on-demand pricing and dedicated nodes split the first gate, and the place where dedicated nodes and self-hosting split the second gate. This post closes each with a formula, and shows you where to read each input off the vendor price list and your own cloud bill.

Analogy

Say you need a warehouse for your goods. Three contracts are on the table.

Metered contract. You pay a storage fee by floor area, and every time you pull one box out you pay a retrieval fee scaled to the whole warehouse's floor area. The reason one box is priced off the entire floor is that the keeper walks the whole warehouse every time. There is also a cap on retrievals per day, and you pay an inbound fee whenever you bring new boxes in
Flat contract. You lease one whole building. You still pay the storage and inbound fees, but the rent is fixed and it costs the same however often you pull things out. More goods means leasing more buildings, and tolerating one building going dark means keeping a spare
Build your own. You lease land and put up the warehouse. Shelving only comes in fixed lengths, so there is always slack. And you have to hire the keeper yourself

Goods are vectors, floor area is namespace size, retrieval is a query, building rent is the dedicated node charge, the storage fee is managed storage, the inbound fee is managed writes, shelving is RAM, the fixed length shelving comes in is a step, and the dock workers are vCPU. The first two contracts, on-demand pricing and dedicated nodes, differ only in where they attach the retrieval fee, and the one line item that exists only when you build your own is the keeper's salary. That salary is what this post measures.

Every calculation here stands on one bundle of premises. Below I call it this post’s baseline. There is a single namespace, so every query targets the whole corpus, and only the read axis is measured. A record is 8,192 B, of which only the 1,536-dimension float32 vector lives in RAM at m = 16, while the 2,048 B of ID and metadata sit on disk. There are no updates, so W = 0, and no add-ons are purchased, so A = 0.

The plan is Pinecone Standard, the dedicated node rate is the documentation’s worked example value P = $336.42, the node count assumes one b1 absorbs its own share of peak so you buy k × r of them, and the instance family is r7i with gp3. Peak queries are low enough that shelving, not queries, fixes vCPU (the max in the self-hosted formula below picks the shelving side). All of that is a premise of the arithmetic that follows, not a general fact.

What moves the zero point and what moves the first gate are different things. Managed-only add-ons push the zero point later, caching payload in RAM pulls it earlier, write volume stops leaving a single zero point at all, and changing the instance family relocates the whole staircase.

Going the other way, if queries target a namespace smaller than the corpus, or you move up to Enterprise, only the on-demand unit price changes: the first gate moves and the zero point stays put. How far each one moves, and in which direction, is in the sensitivity table and the excluded-items table.

Record composition and namespace splitting are in the excluded-items table; instance family and ID-plus-metadata size are in the sensitivity table. The plan swaps the unit price inside the on-demand monthly bill, write volume lands on W in the formula table, and managed-only add-ons land on A. Peak lands on the max in the self-hosted vCPU formula. Namespace splitting is not absorbed by any formula below, so an organization that can split has to layer that axis on top of whatever the formulas return.

Only the metered contract prices retrieval as floor area times retrieval count

Start with the billing rule verbatim. Pinecone’s cost documentation defines the query charge like this: “Specifically, a query uses 1 RU for every 1 GB of namespace size, with a minimum of 0.25 RUs per query.” The same document is explicit that top_k and response size have nothing to do with the charge: “only the size of the namespace determines the number of RUs used.”

Set the three contracts side by side.

Contract	Read charge scales with	Storage	Read ceiling	Human hands
On-demand	namespace GB × query count	$0.33/GB/mo	2,000 RU/s by default	none
Dedicated nodes	node count (shards × replicas)	$0.33/GB/mo	none (up to CPU capacity)	choosing shard and replica counts
Self-hosted	nothing (folded into the shelving)	folded into instance and EBS	none (up to CPU capacity)	all of the monthly labor

Sources are the Pinecone price list and the dedicated node documentation (both accessed 2026-08-29). Of the three rows, only the first has a read charge that grows with usage; the other two are contracts where you buy capacity up front.

Convert the read unit price to a monthly basis. This post uses 730 hours per month throughout. That is the AWS convention, and Pinecone’s own documented monthly node rate uses the same figure ($336.42 ÷ 730 = $0.4608, printed in the docs as $0.46/hour).

Item	Value	Basis
Seconds per month	2,628,000	730 × 3,600
RU per query	equal to namespace GB (minimum 0.25)	Pinecone cost documentation
RU unit price (Standard)	$16–$18 per million	price list. “varies by cloud and region”
WU unit price (Standard)	$4–$4.50 per million	same source. Used by W in the formula table
Minimum spend (Standard)	$50 / mo	price list. Enterprise is $500, so the tier has to be stated
Read charge (low end)	$42.048 / (GB × QPS) / mo	2,628,000 × $16 ÷ 10⁶
Read charge (high end)	$47.304 / (GB × QPS) / mo	2,628,000 × $18 ÷ 10⁶

This post uses the low end, $16. The low end favors on-demand pricing, which makes it conservative against the conclusion “self-hosting is cheaper.” Using the high end makes the first gate worse for on-demand. The RU unit price does not enter the second gate at all.

Q is the monthly average query rate. Charges are assessed on total monthly queries, so plugging in peak inflates the on-demand side and tilts the decision toward self-hosting. Peak is used in exactly two places: measuring the rate limit and sizing.

The read charge is the product of corpus size and query count. It rises when the corpus grows even if queries do not, and it rises when queries grow even if the corpus does not. A product outgrows a sum, so there is always a point where this plan stops making sense.

One query is priced off the warehouse floor area, not off the size of the response. That is why pulling something out just once a second already costs 3.57 times one self-hosted instance holding the same goods.

The 0.25 RU minimum only binds below 0.25 GB of namespace, which means below 30,518 vectors. That is why max(S, 0.25) appears in the on-demand monthly formula. It enters the equivalence point and the rate limit alike, so the 0.40% below is unaffected.

Dedicated nodes beat on-demand at 0.40% × shards × replicas of the allowed retrieval volume

A dedicated node is the contract where you lease a whole building at an hourly rate. Pinecone’s documentation gives b1 as an example: “If the rate for b1 nodes on aws-us-east-1 is $336.42/month ($0.46/hour)”. That is a worked example rate inside a conditional clause, not a committed rate on the price list.

Only the equivalence point and the ratio in this section are directly proportional to that rate. The allowable labor budget that follows, and its ceiling, are not. If your quote differs from this rate, the allowable labor budget shifts wholesale by that difference times the shard count times the replica factor.

The ceiling behaves differently. The spot where the ceiling stands has k = 1 for every replica count, so only the replica factor multiplies, and even that holds only while the spot itself stays put. The rate at which the spot relocates is roughly 3.57× this post’s for replica 1, 3.69× for replica 2, and 3.73× for replica 3. A quote above your own replica factor’s multiple has to be re-run through the allowable labor formula with your rate. A different rate moves the zero point too, and the zero point is a staircase, so it has no closed form.

The documentation also lists a t1 node with roughly four times the resources at roughly three times the price, but this post computes with b1 only. P triples, so reading this section for t1 shifts every ratio by 3× (the 20-node threshold becomes 24.0%, not 8.0%). Price per unit of resource is better on t1, but the documentation does not say whether 250 GB per shard is independent of node type, so the k in the zero point could not be recomputed. Storage capacity is 250 GB per shard, and the shard count k is ceil(S ÷ 250).

The point where the on-demand read charge equals the node charge closes on a single product.

RU unit price	Equivalence point S × Q	Against the on-demand default limit
Low end, $16 per million	8.000856 × k × r GB·QPS	0.4000428% × k × r
High end, $18 per million	7.111872 × k × r GB·QPS	0.3555936% × k × r

The right-hand column is this section’s conclusion. What you earn past that point is the on-demand read charge minus P k r, so at twice the threshold you earn P k r, and at 30.7 times it — Example B below — you earn $19,994.59 a month.

On-demand indexes carry a default rate limit. “On-demand indexes are subject to read unit rate limits (default: 2,000 RUs/second per index).” With an S GB namespace, one query consumes S RU, so the highest reachable QPS is 2,000 ÷ S, and the equivalence point is 8.000856 k r ÷ S. Take the ratio and S cancels.

Key

With one shard and one replica, exceeding just 0.40% of the monthly average query volume the on-demand default limit permits already makes dedicated nodes cheaper. This holds whether the corpus is large or small. But as k and r grow, the threshold rises by their product: 0.80% when duplicated, 2.40% for three shards duplicated. Example C below sits at that 2.40% mark.

The 0.40% figure itself only comes out of the rate this post used ($336.42). With a different quote, recompute the ratio as P × k × r ÷ 84,096 (84,096 = $42.048 × 2,000). The 2,000 RU/s is written as a default in the documentation, so it can be raised. Getting the limit doubled halves the ratio, which actually widens the band where on-demand loses.

A warehouse you build yourself buys shelving in steps

Self-hosting puts an open-source engine on instances. This post uses Qdrant. It is Apache License 2.0, so license cost is zero, and it publishes both a sizing formula and raw throughput data.

Shelving length comes from the formula in Qdrant’s capacity planning documentation (accessed 2026-08-29).

base           = point count × replica factor
dense_size     = base × dimensions × 4 B                   (float32)
hnsw_size      = base × m × 2 × 4 B × 1.2                  (default m = 16)
id_tracker     = base × 52 B
disk(payload)  = base × average payload size × 1.5
ram(payload)   = base × average payload size × 1.5 × 3     (when cached)
headroom       = about 20% on final RAM and disk

This post computes the configuration where payload lives on disk only and the RAM cache is off. Turning the ram(payload) line on makes RAM per vector 2.451 times larger. That is in the excluded-items table. Below, I drop the replica factor out of base, size shelving for a single replica, and then buy that many instances. Total shelving is the same and it becomes visible where the steps fall.

The two approaches do not buy the same vCPU. Five million vectors at replica 2 rounds up per replica to 12 vCPU, so infrastructure is $587.95; putting the replica factor into base and rounding once gives 10 vCPU, or $491.38. This post uses the former, which is what you physically have to buy.

Reproducing the documentation’s worked example (1 million points, 768 dimensions, replica 2) through this formula gives RAM 7.3260 GiB and disk 10.7592 GiB. The documentation prints 7.33 and 10.76. The reproduction matches to two decimal places, so I use the formula as written.

The unit the documentation writes as “GB” is GiB, binary. 2,000,000 × 768 × 4 is 6.144×10⁹ bytes, but the documentation prints 5.72, a value you only get by dividing by 2³⁰. The disk example only works if average payload is taken as 1,024 B (8.97 − 6.105 = 2.865 GiB, and 2,000,000 × 1,024 × 1.5 ÷ 2³⁰ = 2.8610). Vendor price lists use decimal GB and engine documentation uses binary GB, so mixing the two in one calculation is off by 7.4%.

At 1,536 dimensions, one vector consumes (6,144 + 153.6 + 52) × 1.2 = 7,619.52 B of shelving and (6,144 + 153.6 + 52 + 2,048 × 1.5) × 1.2 = 11,305.92 B of disk.

The instance family is memory-optimized r7i. I pulled us-east-1 on-demand values from the AWS price feed (feed published 2026-08-29). All nine sizes are exactly $0.06615 / vCPU / hour and all carry 8 GiB / vCPU.

Combining 2, 4, 8, 16, 32, 48, 64, 96, and 192 vCPU produces every even vCPU count from 2 up, and every combination costs the same. So the self-hosted instance bill closes on one expression regardless of combination: vCPU = 2 × ceil(required RAM GiB ÷ 16).

vCPU	$/mo (730h)	Vectors held (1,536-dim)	Query capacity (per second)	Example combination
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

Both columns grow together, so this table alone does not say which fills up first. What decides is the organization’s ratio of query volume to vector count.

The query capacity column comes from values in Qdrant’s raw benchmark data. Loading 1 million vectors at 1,536 dimensions (dbpedia-openai-1M-1536-angular) onto an 8 vCPU / 32 GiB server (Azure Standard D8s v3) and hitting it with 100 parallel clients gives 1,260.53 per second, p95 of 5.22 ms, and precision 0.9666 (row name qdrant-rps-m-16-ef-128, hnsw_ef = 64, no quantization, 25 GB memory ceiling across all engines).

The qdrant-m-16-ef-128 row in the same file has identical parameters but reports 612.54 per second, a 2.06× spread, so the row name has to be recorded for the comparison to close.

I divided that down to 157.56625 per vCPU. This is an assumption, not a measurement. The raw data is a single point at 8 vCPU, and this post scales it linearly from 2 to 72 vCPU. Vector density changes along with it (the measurement is 0.89 GiB per vCPU; this post’s 72 vCPU configuration is 7.9 GiB per vCPU) and the raw data does not separate that axis. The query capacity column above sits on that assumption.

Trap

This throughput figure is a benchmark Qdrant published about its own engine, which tilts it in favor of self-hosting, and the measurement server is an older 2017-generation Azure D8s v3 rather than this post's reference instance, which tilts it the other way. This post could not compute the net of the two tilts.

The cost verdict here, however, never touches that figure. Running 1 million vectors at their own on-demand equivalence — the monthly average query rate at which self-hosted infrastructure equals the on-demand bill at zero keeper salary and one replica, 0.275087 per second, in the table below — shelving demands 0.887029 vCPU while queries demand 0.001746 vCPU. A 508-fold gap. Cutting throughput to one hundredth would not move the cost verdict.

Sizing is a different matter. Sizing is measured on peak, and once the peak one replica absorbs, divided by 315.13 and rounded up, exceeds shelving GiB divided by 16 and rounded up, queries rather than shelving fix vCPU. That starts above 315.13 per second per replica at 1 million vectors and 1,575.66 at 10 million (multiples of 315.1325 before rounding). The max in the self-hosted vCPU formula performs that check. Inside that band the staircase moves from shelving to queries, and if peak is high enough the allowable labor budget goes negative at every corpus size, so the zero point disappears entirely. At replica 2, a peak of 500 per second leaves the zero point at 6,764,154, but 2,000 leaves no positive band at all.

Disk is EBS gp3. The AWS EBS pricing page presents it as “a region that charges $0.08 per GB-month” without naming the region. It stays inside 2% of self-hosted infrastructure cost, so being wrong by a factor of two moves the total within 2%.

This is where the steps appear. vCPU can only be bought in units of 2 and EBS only in units of 1 GiB. Computed continuously, the cost per GB of namespace looks like this.

Item	Value	Derivation
Vectors per GB of namespace	122,070.3125	10⁹ ÷ 8,192
Shelving	0.866239 GiB	122,070.3125 × 7,619.52 ÷ 2³⁰
vCPU (if divisible)	0.108280	0.866239 ÷ 8
Instance	$5.228782 / mo	0.108280 × $48.2895
Disk	1.285334 GiB → $0.102827 / mo	payload included, × $0.08. EBS is provisioned and billed in GiB, so this row alone multiplies a binary quantity by a vendor rate
R (continuous floor)	$5.331609 / (namespace GB) / mo	sum of the two above

R is a floor. You cannot buy 0.108280 of a vCPU, so the real invoice is always higher. How much higher is set by fill rate (shelving GiB ÷ RAM actually purchased), and fill rate does not improve as the corpus grows. Just past a step is the worst case. Every table and example below computes with the integer instances you actually buy.

For a duplicated 2-million-vector corpus, the band from 0.278 to 0.977 queries per second is where on-demand is cheaper than dedicated nodes but more expensive than self-hosting at zero keeper salary. Adding salary pushes the left crossing right and narrows the band (at $400 a month it starts at 0.858). Comparing only on-demand against dedicated nodes and stopping there misses this band entirely. The on-demand equivalence of 0.134897 in the later table is a single-replica figure, which is why it differs from the 0.278 here.

The second gate closes on the keeper’s salary alone

Set the metered contract against building your own. Computing the query volume at which self-hosting becomes cheaper than on-demand, at zero keeper salary and one replica, gives this.

Vectors	S (GB)	Fill rate	Infrastructure (replica 1)	On-demand equivalence Q*	Against the equivalence floor
300,000	2.458	13.3%	$96.90	0.929849	7.82×
1,000,000	8.192	44.4%	$97.46	0.275087	2.31×
2,000,000	16.384	88.7%	$98.34	0.134897	1.13×
5,000,000	40.960	73.9%	$293.98	0.162842	1.37×
10,000,000	81.920	88.7%	$491.38	0.134804	1.13×
100,000,000	819.200	98.6%	$4,430.30	0.120769	1.02×

The on-demand equivalence implied by the continuous floor R is (R − $0.33) ÷ $42.048 = 0.118950 per second, and I call that the on-demand equivalence floor. No row in the table sits at that value; all of them sit above it. And it does not descend monotonically. It falls to 1.13× at 2 million, then climbs back to 1.37× at 5 million, because 5 million vectors just cross the 6 vCPU step and fill rate drops to 73.9%. A 300,000-vector organization that trusts the floor and self-hosts at 0.2 per second loses money: its on-demand equivalence is 0.93 per second even at zero salary.

Set dedicated nodes directly against self-hosting and the average query volume disappears. Both are contracts where you buy capacity, so the cost is the same however often you pull things out. What remains is shelving and the keeper’s salary, the building rent, storage fee, and inbound fee that exist only off self-hosting, and managed-only add-ons. Peak only raises self-hosted infrastructure, and so lowers the allowable labor budget, inside the band where it overrides shelving to fix vCPU.

Key

Self-hosting is cheaper than dedicated nodes under exactly one condition: monthly labor < L. The allowable labor budget is L = P k r + W + A − (self-hosted infrastructure − s S), where P is the monthly dedicated node rate, k the shard count, r the replica factor, W the managed write bill (0 with no updates), A managed-only add-ons (0 if you do not buy them), s the managed storage unit price ($0.33), and S the namespace in GB. If L is negative, self-hosting loses even with monthly labor booked at zero.

With k = 1 and P = $336.42, here is L by corpus size. Self-hosted infrastructure is computed with integer vCPU and integer EBS, and these are values from the band where peak is low enough that shelving fixes vCPU. When peak fixes vCPU instead, L drops accordingly (at 2 million vectors and replica 2, a peak of 1,200 per second turns $481.57 into $288.41).

Vectors	S (GB)	Shelving/node	vCPU	Infrastructure (replica 1)	Allowable L (replica 1)	Infrastructure (replica 2)	Allowable L (replica 2)
300,000	2.458	2.13 GiB	2	$96.90	$240.33	$193.80	$479.85
1,000,000	8.192	7.10 GiB	2	$97.46	$241.66	$194.92	$480.63
2,000,000	16.384	14.19 GiB	2	$98.34	$243.49	$196.68	$481.57
5,000,000	40.960	35.48 GiB	6	$293.98	$55.96	$587.95	$98.40
6,764,154	55.412	48.00 GiB (under)	6	$295.50	$59.21	$590.99	$100.13
6,764,155	55.412	48.00 GiB (over)	8	$392.08	−$37.37	$784.15	−$93.03
9,000,000	73.728	63.87 GiB	8	$393.92	−$33.17	$787.83	−$90.66

Between 6,764,154 and 6,764,155 vectors is this post’s answer. One more vector pushes shelving past 48 GiB, which forces two more vCPU, and that $96.58 drives the allowable labor budget negative. Above that it never returns to positive within this post’s baseline.

The allowable labor budget rises inside a shelving step and falls when it crosses one. Inside a step the dedicated node charge grows $0.33 per GB while self-hosting grows only the EBS charge, $0.10 per GB per replica. As replicas increase that gap narrows, so the in-step rise flattens, and because EBS attaches in integer GiB it becomes a sawtooth even inside a step. Crossing the first step at 18.47 GB, replica 1 rises $4.26 and replica 2 rises $2.42. Adding replicas raises the curve left of the zero point and lowers it to the right, but the place where the sign flips stays at 6,764,154 on this post's baseline.

On this post’s baseline, the ceilings for replica 1 and 2 are $244.02 and $481.94, both at the top of the shelving step, 2,254,718 vectors. Replica 3 peaks earlier, at 2,184,347, with $719.91, because that is where disk just fails to cross 23 GiB and one less GiB of EBS attaches. As replicas increase, the value of that 1 GiB scales with the replica count too, so the location of the ceiling shifts.

This ceiling is not directly proportional to the monthly dedicated node rate P. At 1.5× the quote ($504.63), the replica 2 ceiling is $818.36 rather than $722.91, and at the t1 rate ($1,009.26) it is $1,827.62 rather than $1,445.81. The first step where the ceiling stands is inside 18.47 GB of corpus, so k = 1 for any node type, and a ceiling with a swapped-in rate comes out without shard uncertainty.

Key

On this post's baseline, the allowable labor budget never exceeds $481.94 at replica 2, for any corpus size. Costing an engineer-day at $500, that falls $18.06 short of one engineer-day per month. An organization that has to attach one engineer-day a month to a duplicated pair of vector databases loses by self-hosting at every corpus size where dedicated nodes can be bought while keeping the replicas. When duplicated, that range runs to 2,500 GB; above it you have to cut replicas to buy dedicated nodes, so it stops being a duplicated-to-duplicated comparison (past 5,000 GB no replica count can buy them at all — see the excluded-items table). Make the call in dollars and treat engineer-days as reference only.

This ceiling is measured with write and add-on charges removed, that is at W = 0 and A = 0. A is independent of corpus size, so the ceiling simply rises by A. W is different, because it scales with vector count. As the update rate rises, the location of the ceiling shifts first, and past that L rises with corpus size until there is no ceiling at all. So an organization with updates does not have those three per-replica values as its ceiling; it has to re-run the allowable labor formula with its own W at its own corpus size.

Below are the values at a 1% daily update rate. The replica 2 ceiling is $526.88, so for an organization booking one engineer-day a month the answer flips to self-hosting from roughly 975,000 vectors up to the top of the first step at 2,254,718. Buying the HIPAA add-on on top takes that organization’s replica 2 ceiling to $716.88 (about 1.43 engineer-days), which flips the one-engineer-day answer to self-hosting all the way to 4,509,436 vectors (see the excluded-items table).

Inside the band where peak is low enough that shelving fixes vCPU, adding one replica raises the allowable labor budget by P k minus one replica’s infrastructure. The table above has k = 1, so the difference between the two L columns is that value on each row, and on the two rows at the 8 vCPU step it is negative, meaning adding replicas actually reduces it.

Replica 3, in the same band, is replica 2 plus that increment once more. Yet the vector count at which the allowable labor budget crosses zero is the same 6,764,154 for replica 1, 2, and 3 on this post’s baseline, because within that baseline what flips the sign is the shelving step, not the replica count.

Trap

This is not a comparison of like architectures. The documentation describes b1 only as "vector index stored in memory" and does not say whether the vector bodies themselves go into RAM. This post's self-hosted configuration puts every vector in RAM as float32. If b1 does not hold vector bodies in RAM, then this post's self-hosted configuration is over-provisioned, and this post could not determine which it is. So the conclusion above is not "dedicated nodes are necessarily cheaper" but only "get a dedicated node quote before you price out self-hosting."

Labor splits self-hosting from dedicated nodes, and query volume splits the survivor from on-demand

All three organizations run 1,536 dimensions, 2,048 B of ID and metadata, and 8,192 B records, with no updates so W = 0 and no add-ons so A = 0. Charges are assessed on monthly average query volume, while the rate limit and sizing are measured on peak. The on-demand limit binds on instantaneous RU/s, so measuring it on the average misses the throttled band. Read peak off the per-second maximum request count (p100) in your cloud console.

Example A — internal document search at a 400-person company

300,000 vectors, monthly average 0.05 per second, peak 0.5 per second. Namespace 2.4576 GB.

On-demand is storage $0.81 + reads $5.17 = $5.98, which hits the minimum spend and bills $50.00. Dedicated nodes are one shard, one replica at $336.42 plus storage, so $337.23. Self-hosting has 2.13 GiB of shelving, so 2 vCPU (fill rate 13.3%) plus 4 GiB of EBS for $96.90, and the keeper's salary goes on top of that.

Answer: on-demand. Self-hosting is 1.94 times on-demand even with monthly labor booked at zero. Average utilization is 0.006144% of the limit (813.80 per second), one sixty-fifth of the 0.40% threshold, so dedicated nodes are premature too. The 0.5 peak is 0.0614% of the limit, so throttling is irrelevant.

Example B — a company selling a product recommendation API

2 million vectors, monthly average 30 per second, peak 60 per second. Namespace 16.384 GB. It is a service, so it is duplicated.

On-demand is storage $5.41 + reads $20,667.43 = $20,672.84. Average utilization is 24.576% of the limit (122.07 per second), 30.7 times the 0.80% threshold, and the 60 peak at 49.15% is inside the limit. Dedicated nodes are one shard, two replicas at $672.84 + storage $5.41 = $678.25. Self-hosting has 14.19 GiB per replica, so 2 vCPU (fill rate 88.7%) plus 22 GiB of EBS, two of them, totaling $196.68. Query capacity across both copies is 630.27 per second, 10.5 times peak.

Answer: self-hosting. It saves $20,476.16 a month against on-demand. Against dedicated nodes the allowable labor budget is $678.25 − $196.68 = $481.57 (about 0.96 engineer-days at $500 a day). Build effort is not stacked on top of that; it is repaid out of the savings. Payback is build cost ÷ (allowable labor − monthly labor), so at zero monthly labor five engineer-days ($2,500) pays back in 5.19 months, at $200 a month in 8.88 months, and once monthly labor reaches $481.57 it never pays back. These are values for a static corpus. If it grows, self-hosting climbs a step, savings shrink, and there is a growth rate at which it never pays back even at zero labor.

Example C — company-wide knowledge base RAG

80 million vectors, monthly average 2 per second, peak 3 per second. Namespace 655.36 GB. Duplicated.

Average utilization is 65.536% of the limit (3.0518 per second), past the 2.40% threshold, and the 3 peak at 98.30% puts on-demand right at the edge of throttling. The bill is $216.27 + $55,113.15 = $55,329.42. Dedicated nodes are three shards, two replicas at $2,018.52 + storage $216.27 = $2,234.79, one 24.76th of on-demand. Self-hosting has 567.70 GiB per replica, so 72 vCPU (fill rate 98.6%) plus 843 GiB of EBS, two of them, totaling $7,088.57.

Answer: dedicated nodes. Self-hosting is 3.17 times dedicated nodes and the allowable labor budget is −$4,853.78, so it loses even at zero monthly labor. Whether quantization can flip this answer does not close on this post's evidence. Qdrant's documentation states that it stores the quantized copy alongside the originals, so what stays in RAM varies by configuration, and this post could not verify that combination. Putting vectors on disk cuts shelving 30.88-fold and does flip this organization's answer (see the excluded-items table), but the throughput of that configuration could not be obtained, so it does not close for the same reason. I will not flip an answer on unverified sizing. If queries can be confined to a 2-million-vector hot namespace the answer flips to on-demand, but that takes the remaining 78 million out of search (see the excluded-items table).

Line the three up by query volume and 0.05 → on-demand, 2 → dedicated nodes, 30 → self-hosting looks monotonic, but that is a coincidence of these three examples. After removing what you cannot buy, the answer splits in two stages. The second gate opens first and eliminates either self-hosting or dedicated nodes; the survivor then competes with on-demand. The gate numbers are the order in which this post measured them, and the order in which answers split is the reverse.

What decides the second gate is the comparison of monthly labor against the allowable labor budget L. Average query volume does not enter here, and peak enters only through L, inside the band where it overrides shelving to fix vCPU. If L is negative, self-hosting drops out first even with labor at zero.

What decides the remaining comparison is average query volume, but the threshold depends on which option survived. If dedicated nodes survived, it is the first gate’s 0.40% × k × r. If self-hosting survived, it is the query volume at which the self-hosted monthly bill equals the on-demand monthly bill, and you have to set the two monthly bills in the formula table equal and solve with your own values.

One caveat: the on-demand monthly bill is flat with respect to Q in the band where it fails to reach the minimum spend, so if your solved value falls in that band it is not a root. In that case just compare the flat on-demand bill against the self-hosted bill.

Monthly labor, the write charge W, and add-ons A all enter that spot, so you cannot reuse the on-demand equivalence Q* from the earlier table. That table is at zero salary, one replica, W = 0, and A = 0. Adding labor alone pushes the threshold right, and once labor reaches L it travels all the way to the first gate’s position (0.278 becomes 0.977 at 2 million duplicated).

Example C drops out at the second gate, so its answer stays dedicated nodes even if you raise query volume tenfold, because the allowable labor budget of −$4,853.78 means the staircase already removed self-hosting. Examples A and B are the opposite: both sit inside the first step (2 vCPU) with allowable labor budgets of +$240.33 and +$481.57, both positive, and yet the answers split to on-demand and self-hosting. The remaining comparison split them at 0.05 versus 30 queries per second, and the point where A crosses over to self-hosting is an on-demand equivalence of 0.929849 at zero keeper salary.

The three monthly bills and the allowable labor budget come out of formulas, and the zero point attaches to vectors, not GB

Collecting the calculations the three examples demonstrated end to end gives these formulas. Read the values off your own invoice and price list and you get the three monthly bills and the allowable labor budget.

Value	Formula
S (namespace GB)	record count × record size B ÷ 10⁹. Record size B = ID and metadata + dimensions × 4 B, which is 8,192 in this post
Shard count k	ceil(S ÷ 250)
On-demand monthly	max(minimum spend, (2,628,000 × RU unit price ÷ 10⁶) × max(S, 0.25) × average Q + s S + W) + A. At this post’s $16 RU the coefficient is $42.048. A sits outside the max because add-ons are a subscription rather than usage, but the price list does not say whether the minimum spend absorbs add-ons. If it does, on-demand gets cheaper by the add-on amount, and at Example A’s usage level of $5.98 a month it stops at $44.02. Average Q (per second) = total monthly queries ÷ 2,628,000
Dedicated node monthly	P k r + s S + W + A. A is managed-only add-ons (HIPAA $190/mo, support Developer $29/mo or Pro $250/mo) and attaches to the on-demand bill equally. Until you have a quote for one b1’s query capacity, this value is a floor
Shelving GiB, disk GiB	record count × RAM per vector B ÷ 2³⁰, record count × disk per vector B ÷ 2³⁰. Mixing these with S’s 10⁹ is off by 7.4%
Self-hosted monthly	self-hosted infrastructure = r × (vCPU × monthly vCPU rate + ceil(disk GiB) × EBS unit price). Self-hosted monthly = infrastructure + monthly labor. vCPU = 2 × ceil(max(shelving GiB ÷ 16, peak Q ÷ r ÷ (per-vCPU throughput × 2))). This post’s throughput of 157.56625 makes the second term’s denominator 315.13. This formula assumes all r copies are alive, so if you must absorb peak with one copy dead, replace the r in the denominator with r − 1 (replica 1 cannot meet that requirement through replication at all). Inside the band where peak fixes vCPU, that substitution flips the sign (at 2 million vectors, replica 2, peak 1,200 per second, L goes from +$288.41 to −$97.91)
Managed write monthly W	monthly updated records × record KB × 2 × WU unit price. Record KB is decimal (record B ÷ 1,000), and the ×2 is because overwriting an existing record charges the old copy once more: the documentation says it “uses 1 WU for each 1 KB of the existing record as well.” Monthly updated records = vector count × daily update rate × 30.4167 (730 hours ÷ 24). It attaches to on-demand and dedicated nodes equally, and is 0 for self-hosting
Allowable labor L	dedicated node monthly − self-hosted infrastructure = P k r + W + A − (self-hosted infrastructure − s S). With no updates W = 0; with no add-ons A = 0. An organization at 6,764,155 vectors, replica 1, and zero labor is at −$37.37 with A = 0, so dedicated nodes win, but buying HIPAA and Pro support makes A = $440 and L = +$402.63, so self-hosting wins

What differs by organization in this table is record count, replica factor, average Q, peak Q, update rate, and monthly labor, plus the monthly dedicated node rate P you get from your own quote and the add-ons A you actually buy. The rest you read straight off the price list and your own instances. Do not pin P to a price list value. This post’s $336.42 is the documentation’s worked example rate.

First, remove what you cannot use. If peak Q ÷ (2,000 ÷ max(S, 0.25)) exceeds 100% and you cannot get the limit raised, on-demand is out. If k exceeds 20 (corpus over 5,000 GB), no r can buy dedicated nodes. If k is 20 or under but k × r exceeds 20, you have to lower r to 20 ÷ k or less to buy them, and what you give up in that case is replication. Re-run the three monthly bills at the lowered r and set that configuration beside your original one.

Then pick the cheapest of what remains. Compute monthly labor as engineer-days committed per month × cost per engineer-day, including on-call, version upgrades, incident response, and compliance work. Cost per engineer-day is loaded salary ÷ working days per year, using your own organization’s figures. If that figure exceeds L, self-hosting loses to dedicated nodes. Example B demonstrates how many months it takes to recover build cost, but this post has no growth model, so it does not offer that month count to an organization whose corpus is growing.

Example A came out on-demand, Example B self-hosting, and Example C dedicated nodes. That is why all three have to be computed. Stopping at “on-demand is cheaper than dedicated nodes” misses the places where self-hosting is cheaper still. For a 2-million-vector, duplicated organization at 0.5 queries per second, on-demand’s $349.86 beats dedicated nodes’ $678.25, but self-hosted infrastructure is $196.68, so self-hosting is cheapest as long as monthly labor does not exceed $153.18. That labor threshold is the on-demand monthly bill minus self-hosted infrastructure, so write and add-on charges raise it by their amount.

In the earlier chart for the duplicated 2-million-vector corpus, that is the 0.278 to 0.977 per second band where the on-demand line runs between the self-hosted and dedicated node lines, and 71.6% of the band where on-demand beats dedicated nodes falls inside it. That ratio comes out as (L − monthly labor) ÷ (P k r), and the 71.6% is the zero-labor value, dropping to 41.8% at $200 a month. At 5 million vectors and replica 1 it is 16.6% at zero labor.

If write or add-on charges are large enough to push that ratio past 100%, the entire band where on-demand beats dedicated nodes belongs to self-hosting (131.1% at 1 million vectors, replica 1, and a 10% daily update rate).

Read the parameters and unit prices for the formulas out of your own environment. This post’s $48.2895 and $0.08 are r7i and gp3 values, and the AWS page does not name the region for the gp3 price. Read m off your Qdrant collection’s hnsw_config.m, average ID and metadata size off a sample of your records, total monthly queries off your invoice, and peak Q off the per-second maximum request count (p100) in your cloud console.

RAM and disk per vector are 7,619.52 B and 11,305.92 B at 1,536 dimensions, m = 16, 2,048 B of ID and metadata, and vectors in RAM as float32. Change the dimensions, m, or ID and metadata and recompute as (dimensions × 4 + m × 9.6 + 52) × 1.2 and (dimensions × 4 + m × 9.6 + 52 + ID and metadata B × 1.5) × 1.2.

A configuration that does not hold vectors in RAM as float32 cannot be computed with these formulas. Layering on a quantized copy, or putting vectors on disk, changes what stays in RAM depending on configuration, and this post could not verify those combinations. For such a configuration, measure your own instance’s RSS ÷ vector count and put that in the RAM-per-vector slot. The per-vCPU throughput of 157.56625 also has to be re-read from a benchmark row measured on that configuration. Because the vCPU formula takes the larger of RAM and queries, cutting RAM alone while leaving throughput as-is means the saving is absorbed on the query side and buys you nothing.

Sensitivity (what changes R)	R (continuous floor)	On-demand equivalence floor	Allowable labor zero point
This post’s basis (r7i, 2,048 B ID and metadata)	$5.331609	0.118950	55.41 GB (6,764,154 vectors)
No ID or metadata (6,144 B record)	$7.064108	0.160153	41.56 GB (6,764,154 vectors)
Graviton3 (r7g, $0.05355/vCPU/hour)	$4.335650	0.095264	73.88 GB (9,018,872 vectors)

Removing ID and metadata pulls the zero point 25% earlier in GB terms while moving it not one vector. RAM scales only with vector bytes and ID and metadata go to disk, so the shelving step is unchanged. The zero point attaches to a vector count, not to gigabytes.

Switching to Graviton3 buys one more step, pushing the zero point 33% later in vector terms. The r7g unit price came from the same AWS price feed (accessed 2026-08-29), and because the 157.56625 throughput was measured on x86, per-vCPU throughput for r7g could not be obtained. This row cannot be used inside the band where peak fixes vCPU. All three rows assume vectors in RAM as float32; quantized configurations and configurations with vectors on disk are not in this table.

What has a magnitude is add-ons, payload cache, and write charges, and write charges do not leave a single zero point

Excluded item	Which way it pushes the zero point	Basis and magnitude
Vectors on disk (mmap)	later. Magnitude is set by throughput	Putting vector bodies on disk and keeping only the HNSW graph and IDs in RAM makes RAM per vector (m × 9.6 + 52) × 1.2 = 246.72 B, per the cold tier convention in Qdrant’s capacity planning documentation (accessed 2026-08-30). Shelving shrinks 30.88-fold, flipping Example C’s allowable labor budget from −$4,853.78 to +$1,713.59. But that is the value for an organization like Example C where shelving fixes vCPU. Because the self-hosted vCPU formula takes the larger of RAM and queries, inside the band where queries decide, the saving is absorbed entirely and the value equals float32 (at 1 million vectors, replica 2, peak 2,000 per second, both are −$98.85). How far it flips is set by this configuration’s throughput, and this post could not obtain that figure or its p95 latency. This configuration reads disk on every query, so gp3’s baseline 3,000 IOPS and 125 MB/s may bind first, with the excess charged at $0.005/IOPS/mo and $0.06/(MB/s)/mo from the EBS pricing page (accessed 2026-08-29). By that much, this lever’s saving is smaller than written above
Vector quantization	direction unknown	Putting the quantized copy in RAM and demoting the originals to disk shrinks shelving, but Qdrant’s capacity planning documentation says “Qdrant stores this compressed copy alongside the original vectors” and that the quantized copy’s tier follows the original’s tier (accessed 2026-08-30). In a configuration that keeps originals in RAM and layers the quantized copy on top, shelving actually grows. The direction splits by configuration and this post could not verify the combinations. If you already use quantization, putting your own instance’s RSS ÷ vector count and throughput measured on that configuration into the self-hosted vCPU formula gives you your own zero point. Putting in RAM alone and leaving throughput at the default makes the max in that formula pick the query side and the saving disappears
Write charges	no single zero point remains. Magnitude comes from the formula table	Both managed options bill by the same rule and only self-hosting is 0. It is zero in dollars, but this post did not measure self-hosting’s indexing compute load (the benchmark cited is a search-only row), and by that much it treated self-hosting favorably. Updating 1% of Example B’s corpus daily is 9.97 million WU = $39.87 a month, or $0.00001993 per vector per month (20.3% of the $196.68 self-hosted infrastructure). Put that update rate into L and the sign does not change just once. W scales with vector count while self-hosting is a staircase, so L becomes a sawtooth, and at replica 1 the last positive spot is 31,566,052 vectors while more than half the range below it is negative. An organization with updates should not read the zero point but instead put its own vector count into the formula table. 6.76 million is a single boundary only when there are no updates
Commitment and annual contract discounts	direction unknown	Computed at on-demand list price. The AWS primary price file is 435 MB, so this post could not read it. Looking at the AWS discount alone, the staircase lowers and the zero point moves later, but the Pinecone annual contract discount rate could not be obtained, so the direction is undetermined. You need both rates to get a direction
Qdrant payload RAM cache	earlier. Magnitude available	This post turned it off. So payload stays on disk only, and this post did not measure its lookup latency. Turning it on takes RAM per vector from 7,619.52 to 18,678.72 B, 2.451 times, and the step count grows accordingly. Because of rounding up, the multiple is not exactly preserved (Example C goes from 36 to 87 steps). The zero point pulls earlier from 6,764,154 to 2,759,268 vectors (22.60 GB) and is the same at replica 1, 2, and 3
Gap between nominal and usable instance RAM	earlier. Magnitude not obtained	Qdrant’s recommended 20% headroom is in the sizing, but you cannot use all of EC2’s nominal memory. What binds first is the organization with the highest fill rate, and this post’s zero point is exactly that spot. Per the table above, shelving of 48.00 GiB fills the 6 vCPU RAM completely, leaving no headroom. Among the three examples, Example C at 98.6% buys one more step if it is short by just 1.44% (Example B does not move until 11.30%)
Migration and build effort	outside the zero point	On the self-hosted side, Example B computed it as months to payback. This post did not measure the effort to move to dedicated nodes, and by that much it treated dedicated nodes favorably
Query capacity of one b1 node	direction unknown	The documentation does not say. This post computed only the cost equivalence point and did not compute $/QPS for dedicated nodes. If a real quote requires more replicas than this post assumes, it moves toward self-hosting. The magnitude is enough to flip the entire allowable labor budget inside the first step. This post prices 2 million vectors, replica 2, peak 2,000 per second as 2 nodes at $678.25, but if a quote demands 6 nodes then dedicated nodes are $2,023.93 and self-hosting at $776.15 is $1,247.77 a month cheaper
Architectural difference between b1 and RAM-resident self-hosting	direction unknown	The documentation does not say whether b1 holds vector bodies in RAM
Namespace splitting	outside the zero point. Pushes the first gate strongly toward on-demand	Pinecone’s cost documentation states “The cost of a query scales linearly with the size of the targeted namespace” (accessed 2026-08-30). This post has a single namespace, so it set targeted size = corpus. If you can split, the on-demand read charge falls by that ratio. If Example C confines queries to a 2-million-vector hot namespace, on-demand drops from $55,329.42 to $1,594.10, cheaper than dedicated nodes’ $2,234.79, and limit utilization goes from 98.30% to 2.46%, flipping the answer to on-demand. What you give up is search coverage. Example C takes 78 million of its 80 million (97.5%) out of query reach, so this is a product behavior change rather than a pricing lever, and it is unusable if any query has to find things outside the hot set. Dedicated nodes use only one namespace per the documentation, so this lever does not exist for them
Dedicated node count ceiling	outside the zero point. Above k > 20 it leaves the candidate set; below that you have to cut r to buy	The dedicated node documentation lists 20 per project as the ceiling (accessed 2026-08-29). Past k = 20 (corpus over 5,000 GB) no r can buy them, and below that, if k × r exceeds 20 you have to cut r to 20 ÷ k or less. The corpus you can cover while keeping replicas runs to 5,000 GB at replica 1, 2,500 GB at replica 2, and 1,500 GB at replica 3
Raising the on-demand rate limit	outside the zero point	Moves only the first gate (on-demand versus dedicated nodes). The 2,000 RU/s is a default, and raising it shrinks the equivalence ratio by the same factor
Corpus and query growth	outside the zero point. Sets the month the answer changes	This post’s formulas produce today’s values. Shelving steps, shard boundaries, the on-demand limit, and the 20-node ceiling bind in turn, and the on-demand monthly bill, proportional to S, passes continuously through the staircase of self-hosting. When it passes is set by monthly growth, and this post did not measure that
Managed open source	outside the zero point. Opens a fourth candidate	This post compared only Pinecone’s two plans and self-hosting, and could not obtain primary-source pricing for managed offerings of the same Apache 2.0 engine. An organization whose labor exceeds L should get a separate quote for this candidate
Egress	outside the zero point. Symmetric	AWS and Pinecone both include 100 GB a month free. The Pinecone price list gives an overage rate of $0.10/GB (accessed 2026-08-29). The AWS overage rate could not be obtained, so the symmetry verdict is half-founded by that much
Managed-only add-ons (compliance and support)	later. Magnitude available	The Pinecone price list lists a HIPAA add-on at $190/mo and support add-ons at Developer $29/mo and Pro $250/mo on Standard (accessed 2026-08-29). They attach only to on-demand and dedicated nodes, so the allowable labor budget L grows by that amount and the zero point pushes later. With HIPAA the zero point goes from 6,764,154 to 11,273,590 at replica 1 and to 9,018,872 at replicas 2 and 3; with Pro support, to 13,528,308 at replica 1 and 9,018,872 at replicas 2 and 3; with both, to 18,037,744 at replica 1 and 11,273,590 at replicas 2 and 3. HIPAA alone flips L at 6,764,155 vectors and replica 2 from −$93.03 to +$96.97 and takes the ceiling from $481.94 to $671.94. Self-hosting absorbs this item as labor, so how you price that side can reverse the direction

The rows split like this. Ones that push the zero point later (vectors on disk, managed-only add-ons), ones that pull it earlier (payload RAM cache, the nominal RAM gap), one that stops leaving a single boundary (write charges), ones whose direction is undetermined (quantization, commitment discounts, b1 query capacity, b1 architecture), and ones that move things outside the zero point.

What has a magnitude is managed-only add-ons, the payload RAM cache, and write charges. Managed-only add-ons push replica 1’s zero point to 11.27 million with HIPAA and 13.53 million with Pro support, and the payload RAM cache pulls it to 2.76 million. Write charges have a magnitude, but rather than moving the zero point to a single spot they turn L into a sawtooth. Commitment discounts could not even produce a direction because both rates were unavailable, the nominal RAM gap gives only a direction because it varies by instance, and vectors on disk give only a direction because the throughput for that configuration is missing.

So 6,764,154 is not this post’s conclusion but the conclusion for the configuration this post computed. Depart from any one of the baseline premises and the zero point or the first gate moves. Put your own configuration’s RAM per vector and throughput into the self-hosted vCPU formula and you get the sign of your own allowable labor budget at your own corpus size.

Part 1 built its structure on the crossing of fixed cost and metered cost, and this post moves that structure to vector databases. One thing differs. In Part 1 the fixed cost was a constant; here the self-hosted cost follows the corpus as a staircase, so what flips the sign is not corpus size itself but the moment of crossing a step.

Part 4 covered the indexing cost of the same corpus. Part 4 measured write charges and left read charges open, and this post measures those read charges. The 8,192 B record and the decimal GB convention carry over from Part 4 unchanged.

Both of this post’s splits stand on the Pinecone price list and the AWS price feed. If those values change, so do 8.0 GB·QPS and 6,764,154. What does not change is the structure. The metered contract prices retrieval as floor area times retrieval count, and the other two price it on floor area alone. A product outgrows a sum, so the first gate necessarily exists, and its position is always low relative to the retrieval volume you are allowed.

How low comes out of the fact that dedicated nodes cap at 20 per project. The threshold P k r ÷ 84,096 is 0.4000428% × k × r at this post’s rate, so it cannot exceed 8.000856%. Turn that around: if your average utilization exceeds that figure and the configuration is purchasable, dedicated nodes always beat on-demand. The comparison against self-hosting is separate, and Example B is the case that goes to self-hosting even at 24.576% utilization.

The second gate is different. Compare the two contracts that price on floor area alone and the average retrieval count cancels, leaving shelving and the keeper’s salary, the building rent, storage fee, and inbound fee that exist only off self-hosting, and managed-only add-ons. Below 6,764,154, whether to choose self-hosting is a question of how many people you can attach to that warehouse, and on this post’s baseline $481.94 a month at replica 2 is that ceiling.

Above it the only move left is shrinking the shelving, and the one lever that shrinks shelving is putting vectors on disk. Quantization can shrink or grow shelving depending on configuration, so it cannot be established as a lever. The managed side has neither, because its index size formula is fixed at dimensions × 4 B.

On-disk has no magnitude either. Cutting RAM per vector without measuring throughput alongside it means the saving is absorbed on the query side, and obtaining that throughput is the homework this post leaves behind. The 6.76 million is a value for organizations that hold to this post’s baseline, and for those organizations it is a spot they do not come back from.