Do you need a vector database?

Skip to the controls

VectorAI DB / sizing toolno third-party trackers

VERDICTDescribe your workload to see the verdictsee why

Your verdict

updates as you change anything

VERDICT

Describe your workload to see the verdict

The verdict updates as you change any input.

Where your workload sits

items in 12 months, log scale

100Kitems

Flat fileto 163K

Keyword indexany size

pgvectorto 3.5M

Dedicated store3.5M+

What it costs you	Today	In 12 months
Raw vectors, float32	614MB	614MB
Same vectors at int8	154MB	154MB
Comparisons per query	154M	154M
Brute-force scan	31-307ms	31-307ms

WHAT THE MEMORY COSTS

Per month	Today	In 12 months
Memory to provisionindex x 1.5 graph x 1.3 headroom	1.2 GB	1.2 GB
Self-managed memory	$6.67 to $6.73	$6.67 to $6.73
Midpoint	$6.70	$6.70
int8 vectors only	$0.86	$0.86

Memory is raw vectors x HNSW graph overhead x headroom, both estimates. The verdict compares the index without headroom against the memory you set; headroom only prices it. Priced Oct 19, 2026, on-demand list prices, US regions, per decimal GB (10^9 bytes). Whole-instance price spread over its memory, so the vCPUs that come with it are included. Hardware only. Not a quote.

Cost as you scale

memory per month, log scales on both axes

Line is the midpoint. Band is the low to high list price, only 0.9% apart, so it sits under the line.

Monthly memory cost by item count at 1536 dimensions
Items	Low	Mid	High
1,000	$0.07	$0.07	$0.07
10,000	$0.67	$0.67	$0.67
100,000	$6.67	$6.70	$6.73
1,000,000	$67	$67	$67
10,000,000	$667	$670	$673
100,000,000	$6,673	$6,703	$6,733
Your workload, 100,000 items in 12 months	$6.67	$6.70	$6.73

WHY YOU LANDED HERE

scanning 100K vectors of 1536 dimensions takes about 31ms, inside your 50ms target
no metadata filtering and a single workspace, so there is nothing to index around
on slower hardware the same scan could take 307ms, so measure before relying on it

WHAT WOULD CHANGE THIS

If you pass 163K items at 1536 dimensions, add filtering, or go past ten queries per second, revisit this.

ASSUMPTIONS

These are rule-of-thumb estimates, not benchmark results. Replace them with figures from your own hardware and the verdict recalculates. Whatever you set travels with the shared link and appears in the exported record.

Memory available (GB)Drives both ceilings. A flat scan needs the vectors in memory; an HNSW index needs the vectors plus its graph.

HNSW graph overheadEstimate. Multiplier on raw vector size for the HNSW graph links, around m=16. pgvector also keeps a copy of each vector in the table heap, so if the table must stay in memory too, raise this toward 2.5 or more.

Heavy filtering strains aboveItem count above which an always-on metadata filter starts costing recall or latency on a general-purpose planner.

Stacked demands count above (share of pgvector ceiling)Estimate. Hybrid search, many tenants, constant churn and always-on filtering only push toward a dedicated store together, and only once the workload passes this share of what one Postgres instance can index.

Effective throughput, high (GFLOP/s)Optimistic single-node throughput. This sets the flat-scan ceiling, so raising it says a brute-force scan stays viable longer.

Effective throughput, low (GFLOP/s)Pessimistic throughput. Used for the slow end of the scan estimate and to warn when a flat scan is marginal.

Memory headroomEstimate. Multiplier on the index size so the host is not run at its limit. Prices the memory, does not change the verdict.

Memory price, low (USD per GB-month)Per decimal GB (10^9 bytes). Default is the cheaper of the on-demand list prices in the data file, converted from per GiB.

Memory price, high (USD per GB-month)Per decimal GB (10^9 bytes). Default is the dearer of the on-demand list prices in the data file, converted from per GiB.

WORTH READING NEXT

Read the agent memory architecture guide

Bookmark this and run it again when your numbers move.

TAKE IT WITH YOU

The record carries the assumptions you used, not the shipped defaults, so a reviewer can tell whether the model was calibrated.

How this tool decides

The numbers are exact arithmetic. Vector memory is items multiplied by dimensions multiplied by four bytes for float32. Comparisons per query is items multiplied by dimensions, because a brute-force search compares your query against every stored item. Those figures are true for the inputs you set, with no measurement behind them and none needed.

The tier break points are a rough guide. They come from that same arithmetic plus the widely observed behavior of brute-force search and HNSW indexes. They are estimates for sizing a decision, not a benchmark, and your hardware, dimensions and query mix will move them. Every one of them is editable in the assumptions panel, and whatever you set travels with the shared link and the exported record.

The scan figure is an order of magnitude, derived from the throughput range in the assumptions. It tells you whether a flat scan is in the right ballpark, and nothing finer than that.

This page publishes no performance table and no vendor comparison figures. Where the result points at a dedicated vector database, it does so because of the shape of your workload, and the product pages carry the proof from there.

Keep reading

when you don't need one

where simple setups break

agent memory patterns

picking a database

get started