For a startup adding embeddings search, which vector store is cheapest to run?

The absolute cheapest vector store to run for a startup is pgvector (running inside your existing PostgreSQL database) , followed closely by LanceDB for local or edge-based workflows, and Qdrant if you require a dedicated, managed cloud service.

The exact "cheapest" option depends entirely on your existing infrastructure, your data scale, and how much operational overhead your engineering team can handle.

Cost Comparison Framework

The Top 3 Cheapest Options (Detailed Break down)

1. pgvector (PostgreSQL Extension)

If your startup already uses PostgreSQL (via Supabase, Neon , AWS RDS, etc.), adding pgvector introduces no new monthly bills.

• Why it's cheap: You eliminate the "startup tax" of paying for an entirely new database cluster. You also don't have to pay for data transfer between different database vendors.
• The Catch: Vectors take up a lot of RAM. If you scale past a few million vectors, you may need to upgrade your Postgres instance size or implement HNSW indexes, which increase memory consumption.

2. LanceDB (Serverless / Embedded)

LanceDB is an open-source, developer-friendly embedded vector database. It runs directly inside your application process (like SQLite) rather than requiring a standalone server.

• Why it's cheap: It stores its index files directly on disk or in cheap cloud storage like AWS S3 . Because it splits compute from storage, you only pay pennies per gigabyte for the S3 data, and you don't pay for an idle, always-on database server.
• The Catch: Because it is serverless and retrieves index files from disk/S3, it may experience slightly higher latency on the very first query (cold start) compared to an in-memory database.

3. Qdrant

If you explicitly want a dedicated vector database because your core product relies entirely on complex semantic searches, Qdrant offers the best resource efficiency.

• Why it's cheap: Qdrant is written in Rust, making it incredibly lightweight on memory usage. Its managed cloud tier offers a very generous free tier, and its paid clusters are billed purely by the node size rather than hitting you with sneaky per-query fees.
• The Catch: You still have to manage a secondary database connection, adding slight code complexity to your application stack.

Why You Should Avoid Pure "In-Memory" Cloud Tiers Early On

Many popular, fully-managed vector databases store all vectors directly in RAM to achieve lightning-fast speed. While performant, this can cost upwards of $100–$300+ per month even for relatively small datasets. For a pre-revenue startup, this is an unnecessary cash drain. Stick to an embedded or disk-backed architecture until your user base demands sub-millisecond latencies at a massive scale.

If you'd like to narrow this down, let me know:

• What database engine (if any) your startup is currently using?
• Roughly how many items/documents do you plan to embed and search?
• Do you prefer a fully managed cloud service or are you comfortable self-hosting?

If cost is the priority, I’d start with pgvector on the Postgres database you already run.

Cheapest by situation

My startup recommendation: don't add a dedicated vector database initially. If you're already using Postgres, add pgvector. It gives you vector search, metadata filtering, transactions, and your normal relational data in one system. For many startups with a few million vectors and moderate traffic, this is the lowest-cost architecture.

I'd only move to Qdrant/Pinecone/etc. when vector-search scale or latency becomes a meaningful bottleneck.

If you tell me roughly number of documents/vectors, embedding dimensions, queries/day, and whether you're already on Postgres/Supabase, I can estimate the monthly cost of 3–4 options for your actual workload.

For a startup, the cheapest vector store is usually the one you already operate:

1. PostgreSQL + pgvector — cheapest for most startups

• Cost: ~$0 incremental cost if you already have Postgres.
• Best when: - You already use Postgres for application data.
• You have thousands to a few million embeddings.
• You want simple architecture (one database, one backup strategy).
• Downsides: - Not as specialized as a dedicated vector engine at very high scale.
• Large indexes can require more RAM/DB tuning.

2. Qdrant self-hosted — cheapest dedicated vector database

• Cost: commonly a small VPS ($20–50/month range depending on workload).
• Best when: - You want a purpose-built vector engine.
• You need better vector search performance or filtering than your Postgres setup comfortably provides.
• You are comfortable running Docker/backups/monitoring.
• Downsides: - Another service to operate.

3. Chroma self-hosted — cheapest for prototypes

• Cost: free software; can run locally or on your own machine.
• Best when: - You are building an MVP or internal tool.
• You have low traffic.
• Downsides: - You may outgrow it as a production search backend.

4. Managed services (easiest, usually not cheapest)

• Pinecone, Qdrant Cloud, Weaviate, etc. save operational time but generally cost more once usage grows. Free tiers can be enough for early experiments.

My default startup recommendation

A practical rule: do not add a separate vector database until Postgres becomes the bottleneck. For many startups, embeddings search is initially a feature of the application database, not a new infrastructure layer.

If you share your expected scale (number of documents/vectors, QPS, and whether you already use Postgres), the cheapest choice usually becomes obvious.

For an early-stage startup, the "cheapest" vector store depends heavily on where your data already lives , your traffic volume (QPS) , and your tolerance for infrastructure management.

The total cost of ownership (TCO) breaks down across three main deployment archetypes:

1. The Absolute Cheapest (Zero Incremental Infra): pgvector on existing Postgres

If your startup already runs a managed PostgreSQL database (like AWS RDS, Supabase, or Neon), pgvector is virtually free to start.

• Cost Profile: You only pay for the marginal storage and slight CPU overhead on your existing database instance.
• Scale Sweet Spot: Ideal for small-to-medium datasets (up to 1M–5M vectors depending on your RDS instance size).
• The Catch: Once your vector dimensions or dataset scales up (e.g., hitting 10M+ vectors), you will need to vertically scale your Postgres RAM/CPU instance, which can spike database bills unexpectedly. High query throughput can also contend with your primary application database traffic.

2. The Cheapest Dedicated Managed Cloud: Qdrant Cloud

If you need a dedicated vector database and want predictable pricing decoupled from query volume, Qdrant Cloud tends to beat competitors like Pinecone or Weaviate for budget-conscious teams.

• Cost Profile: Uses fixed per-node or tiered resource pricing rather than charging heavily per read/write request. At around 10M vectors, managed Qdrant clusters often run noticeably cheaper than Pinecone Serverless or Weaviate Cloud.
• Scale Sweet Spot: Great for predictable workloads scaling from 1M to 50M vectors where high query traffic won't double your bill overnight.
• The Catch: Requires provisioning cluster nodes rather than pure consumption-based serverless scaling.

3. The Easiest & Fastest MVP (Zero Ops): Pinecone Serverless

While not always the cheapest at mid-to-high scale due to metered read/write unit costs, Pinecone has a baseline entry cost ($50/mo minimum pod/serverless tier structures).

• Cost Profile: Pure pay-as-you-go consumption (storage per GB plus read/write units).
• Scale Sweet Spot: Prototypes and MVPs where engineering time is vastly more expensive than cloud bills.
• The Catch: High query-volume applications can see bills scale aggressively because every search operation is metered.

Cost Comparison at a Glance (Estimated Production Baselines)

To help narrow down the exact right choice, tell me:

• Where is your primary application data hosted (AWS, Supabase, GCP, etc.)?
• Roughly how many vectors do you plan to launch with, and what is your expected dimension size (e.g., 1536 for OpenAI)?
• Do you prefer a fully serverless/hands-off approach or a fixed-cost cluster?

For an early-stage startup adding embeddings search, the absolute cheapest option is pgvector (PostgreSQL extension) if you already run Postgres. If you need a dedicated vector database, Qdrant (self-hosted or via budget cloud) offers the lowest cost-to-performance ratio.

The choice depends heavily on your data scale, team size, and whether you factor in DevOps costs.

1. The Undisputed Budget Winner: pgvector (Postgres Extension)

• Cost: $0 extra (if you already run Postgres) or just the baseline cost of a small managed Postgres instance (e.g., Supabase, AWS RDS, or Render).
• Why it’s cheapest: There is no separate service, no additional cluster to provision, and your relational data and vectors live in the same transaction. An HNSW index inside Postgres easily handles MVPs and scale up to a few million vectors with solid performance.
• When it stops being cheap: When your index grows past 5–10 million vectors or your high-concurrency read/write traffic starts starving your primary application database of RAM and CPU.

2. Cheapest Dedicated Open-Source / Cloud Option: Qdrant

• Cost: Free (self-hosted on a cheap $5–$30/mo VPS like Hetzner or DigitalOcean) or Qdrant Cloud starting at low entry tiers.
• Why it’s cheapest: Written in Rust, Qdrant is remarkably memory- and CPU-efficient compared to other dedicated vector engines. Unlike consumption-based pricing models that spike your bill when query volume jumps, Qdrant's fixed-node model lets you serve high traffic for "free" until you physically outgrow the server limits.
• When it stops being cheap: When you have no DevOps/infrastructure capacity and the engineering hours spent managing, backing up, and scaling a cluster cost more than a managed service.

What about the popular managed options?

• Pinecone: Great for zero-ops and fast shipping, but rarely the cheapest for a small startup. While their serverless tier is inexpensive at very low volumes, their production standard plans carry a fixed monthly minimum ($50/mo+), meaning you pay the same whether you store 10,000 or 2 million vectors. At massive query volumes, consumption-based billing can also surprise you.
• Chroma: Fantastic for local development and prototyping, but less mature for heavy, concurrent production setups compared to Qdrant or pgvector.

Startup Decision Matrix

• If your data is under 5 million vectors and your stack is on Postgres: Use pgvector.
• If you expect high query throughput / heavy filtering and want a dedicated engine without heavy cloud bills: Self-host Qdrant on a small cloud instance.
• If your team has zero DevOps time and needs to ship yesterday regardless of a minor SaaS baseline: Go with Pinecone Serverless or Qdrant Cloud.

If you can share your approximate vector count (e.g., 50K vs 5M) and expected monthly queries , I can calculate a tighter monthly cost projection for your specific setup.

If cost is the primary concern for a startup, I’d rank the options like this:

My recommendation

Start with pgvector if you're already using Postgres. You don't add another database, another bill, or another operational system. Recent 2026 comparisons consistently put pgvector at the lowest total infrastructure cost for workloads below roughly 5–10M vectors.

If you don't want vectors living in your application database, I'd choose Qdrant. Its managed cloud currently has a free tier with 1 GB RAM / 4 GB disk, roughly enough for ~1M 768-dimensional vectors, and it can scale from there on resource-based pricing.

For example, a rough startup progression could be:

0 → 1M vectors: pgvector or Qdrant free = $0 incremental

1 → 10M vectors: Qdrant is generally cheaper than Pinecone/Weaviate; one recent comparison estimates ~$65/month for 10M vectors versus ~$70 Pinecone and ~$135 Weaviate.

100M+ vectors: I'd revisit the architecture—self-hosted pgvector/Qdrant or specialized infrastructure can become dramatically cheaper than per-query managed services.

One important caveat: embedding generation itself can cost more than the vector database if you're ingesting lots of documents. Qdrant even offers some free hosted embedding models, which can further reduce the initial bill.

Bottom line:

• Already on Postgres → pgvector
• Starting fresh and want managed → Qdrant
• Want absolute minimum infrastructure/ops → Pinecone, accepting a higher bill
• Don't prematurely adopt a specialized vector DB unless your scale/search requirements justify it.

If you tell me roughly number of documents/vectors, queries per day, and whether you're already on Postgres, I can estimate the monthly cost for pgvector vs Qdrant vs Pinecone for your startup.

If your goal is the lowest cost for a startup, my default choice is pgvector on Postgres—especially if you already use Postgres.

Cheapest options

pgvector wins on total cost because you don't introduce another database, another network hop, or another bill. Current comparisons also generally find it the cheapest choice below roughly 5–10M vectors when you're already paying for Postgres.

Qdrant is my pick if you specifically want a vector database. Its cloud free tier currently includes 1 GB RAM and 4 GB disk, and its paid pricing is based on CPU/RAM/disk rather than per-query charges.

Pinecone is probably not the cheapest, although it's very convenient. Its current Builder plan is $20/month, while Standard has a $50/month minimum. The free Starter tier is useful for prototypes.

What I'd do

• Already have Postgres: use pgvector.
• Starting from scratch and want managed: use Qdrant.
• Want maximum simplicity and don't mind paying: use Pinecone.
• Don't create a separate vector DB just because you're adding embeddings. For an early-stage startup, Postgres + pgvector is often the economically rational architecture.

If you tell me roughly number of documents/vectors + embedding dimensions + searches/month, I can estimate the monthly cost of pgvector vs Qdrant vs Pinecone for your actual workload.

For an early-stage startup, the absolute cheapest vector store to run is whatever database you are already using for your primary app data (provided it supports vector extensions). Adopting a specialized, separate vector database too early introduces redundant hosting costs, extra synchronization logic, and separate operational overhead.

The most cost-effective routes break down by your startup's stack and scale:

• pgvector (PostgreSQL extension): Cheapest overall if you already run a Postgres instance (on Supabase, Neon , AWS RDS, etc.). It costs $0 extra in infrastructure because your vectors live right alongside your relational data up to roughly 5M to 50M vectors depending on your compute. Combined with open-source tools like pgvectorscale , it handles typical MVP and production RAG workloads cleanly without a second billing meter.
• Qdrant (Self-Hosted): Cheapest dedicated performance engine if you need a standalone service. Running Qdrant via Docker on a modest VPS (like a $30–$50/mo node on Hetzner or DigitalOcean) can store and filter millions of vectors with high throughput. Its Rust-native architecture is exceptionally light on RAM compared to alternatives.
• Cloud Free Tiers / Developer Sandboxes: Cheapest for day-one prototypes ($0/mo) . Providers like Qdrant Cloud (1GB free tier), Pinecone (Serverless starter/free tiers), and Weaviate Cloud (Sandbox) cost nothing during early development and testing phases. Watch out: Pinecone and serverless architectures use query/read-unit meters that can scale up steeply once high-frequency user traffic hits.
• Object-Storage-Backed Engines (e.g., Turbopuffer or self-hosted Mixpeek): Cheapest at scale for massive storage . If you are storing tens of millions of vectors at rest but have low query concurrency, engines built directly on object storage (like S3) bypass expensive hot-RAM cluster minimums.

To help narrow down the exact right fit, tell me:

• How many vectors do you plan to store initially and in 6 months?
• Are you already hosting a primary database (like Postgres or MongoDB)?
• Is your anticipated query traffic low/spiky or high/constant?

For an early-stage startup adding embeddings search, the absolute cheapest option is not adding a new database at all.

• pgvector (PostgreSQL): If your backend already runs on PostgreSQL (via Supabase, Neon , or a managed RDS instance), the incremental cost of pgvector is $0 . Your vectors, metadata, and relational tables live in the same transaction, eliminating a separate synchronization pipeline, extra credentials, and another service to monitor. It comfortably scales to several million vectors before you'll ever need to think about dedicated infrastructure.

If your stack doesn't use Postgres or you expect rapid scaling past 5 million vectors where a dedicated search engine is required, look at these budget-friendly alternatives based on deployment model:

• Qdrant (Self-Hosted): If you have basic Docker or Kubernetes competence, running Qdrant on a cheap VPS (like Hetzner or DigitalOcean for ~ $30/month) yields the best performance-to-cost ratio for filter-heavy and high-throughput vector workloads. It is written in Rust, highly memory-efficient, and features one of the most generous free tiers in the managed cloud space if you prefer not to self-host initially.
• Chroma: Best for local prototyping and early MVPs, allowing you to run embedded storage directly in your application runtime for $0 before paying for managed backends.
• Pinecone (Serverless): While it has usage-based billing that becomes expensive at large scale, its consumption-based serverless tier scales down to zero when idle. For very low query volumes (e.g., a few hundred searches a day on a small corpus), your monthly bill can literally be under ~ $2/month, trading off infrastructure management for a small financial footprint early on.

If you tell me your approximate vector count, expected query volume (QPS) , and current tech stack , I can help you pick the most cost-efficient setup without over-provisioning.

If “cheapest to run” is the priority, my default answer for a startup is pgvector on the Postgres database you already have.

Why pgvector wins: there's no separate vector-database bill—you use your existing Postgres compute/storage. Recent 2026 comparisons consistently put it at the lowest total cost when Postgres is already part of the stack.

If you don't already have Postgres, I'd look closely at Qdrant. Its hosted free tier currently provides a single-node cluster with 1 GB RAM and 4 GB disk, and paid usage is based on the resources your cluster consumes rather than per-query charges.

Pinecone is excellent operationally, but its current paid Builder tier is $20/month, while Standard has a $50/month minimum—so it isn't usually the cost winner for a small startup.

My startup recommendation:

• Already using Postgres → pgvector
• No Postgres, want managed → Qdrant
• Don't want to think about infrastructure at all → Pinecone
• Millions → tens of millions of vectors + sophisticated retrieval → evaluate Qdrant/Weaviate

If you give me number of documents/vectors, embedding dimensions, queries/day, and whether you already use Postgres, I can estimate the monthly cost for each and tell you which is cheapest for your workload.