---
title: "Vector Search Inside a Postgres-Wire-Compatible, Apache-2.0 Database — Why pgvector Users Are Switching"
description: "Three structural ceilings of pgvector at corpus scale: RAM cost, deletes that rot recall, licensing if you want to host it. v3.32 closes all three — over the Postgres wire, under Apache 2.0, with existing clients and ORMs unchanged."
date: 2026-06-15
updated: 2026-06-15
tag: "Strategy"
canonical: https://www.heliosdb.com/blog/vector-search-postgres-wire-apache-2-pgvector.html
---

# Vector Search Inside a Postgres-Wire-Compatible, Apache-2.0 Database — Why pgvector Users Are Switching

If you're running pgvector at meaningful scale, you've hit at least one of three ceilings: RAM cost on big corpora, no first-class deletes that preserve recall, and a licensing wall if you want to host it as a managed service. HeliosDB Nano v3.32 closes all three — over the Postgres wire, with the same clients and ORMs you already use, under Apache 2.0. Zero migration friction, zero lock-in.

## The three ceilings

**RAM cost.** A 1M-document corpus at dim-1536 (OpenAI `text-embedding-3-small`) is ~6 GB of vectors before any graph overhead. Per replica. pgvector's IVFFlat keeps full vectors in memory; HNSW indexes are even hungrier. At ten million documents you're shopping for memory-optimised instances. v3.32's PQ-HNSW path compresses the resident codes ~16× — that 6 GB drops to ~400 MB of codes, with full vectors on disk and an exact two-stage rerank that keeps recall within 0.5 % of the uncompressed baseline.

**Deletes that rot recall.** pgvector's HNSW index supports deletes, but the deleted entries leave tombstones; recall on the affected neighbourhoods degrades silently. For a static corpus that's fine. For anything with churn — doc updates, GDPR right-to-be-forgotten, expiring data — recall drifts down over months and you can't tell why without a recall benchmark in production. v3.32's `remove()` repairs the affected neighbourhood synchronously; recall stays stable under churn. `compact()` reclaims tombstoned space on schedule.

**Licensing.** pgvector itself is permissive (PostgreSQL License). But every commercial managed-Postgres service that ships it is the licensee of *their* service, not yours. Many of the off-the-shelf Rust vector indexes you'd reach for if you wanted to roll your own are BSL or AGPL — fine for an internal tool, a problem if you want to host the database as a service or ship it inside a product. v3.32 is Apache 2.0 end-to-end. You can host it, resell it, embed it, fork it, or strip the branding. Source-available competitors (SSPL / BSL) won't let you do that.

## The wire matters

Nano announces as PostgreSQL on the wire. `psycopg`, `pg-promise`, JDBC, `pg8000`, Drizzle, Prisma, TypeORM, SQLAlchemy, Diesel — all connect with no driver change. SCRAM-SHA-256 works (see [Nano v3.22 → v3.30](https://www.heliosdb.com/blog/nano-3-22-to-3-30-postgres-compat-auth-psql.html)); `information_schema` is populated; `\d` and `\l` return real data. The migration is "change the host, change the password." Not "rewrite the data layer."

And because the wire is Postgres, the rest of your stack doesn't care. Migrations run through your existing tool. Backups run through your existing pipeline. The observability you've already paid for keeps working. The vector index is just a new index type behind the same SQL.

## Three positioning directions

**1. pgvector you can actually host and afford.** The default direction. Same wire, smaller RAM, better deletes, hostable. The wedge into the "I'm paying $4K/month for a memory-optimised Postgres instance because of pgvector" crowd.

**2. Edge and embedded RAG.** A single ~32 MB binary, in-process embeddings via `fastembed`, the persistent index resident on local disk. Run RAG on a Raspberry Pi, a Mac mini at the edge of a venue, an air-gapped customer site. The PQ compression matters more here than in the data centre — RAM ceilings are harder.

**3. Agent memory at scale.** Pair the persistent index with the native MCP server (see [Native MCP Server](https://www.heliosdb.com/blog/native-mcp-server-database-tool-provider.html)) and the git-like branching surface from [Database Branching](https://www.heliosdb.com/blog/database-branching-git-for-your-data.html). An agent has a private branch for its scratchpad; the parent branch is the durable memory; the vector index makes both searchable. The "agentic database" story isn't a buzzword if the primitives compose.

## What it doesn't do

SQL `CREATE INDEX` on the persistent path isn't wired yet — today it's a Rust library API. If your access pattern is "everything via `psql`" you're temporarily on the existing in-RAM `quantized_hnsw` path. That's still useful (and itself benefits from v3.32.1's recall-safe defaults), but the persistent index is library-only until the DDL wiring lands in a follow-on 3.32.x or 3.33.x.

PQ is L2-only. Embedding models that produce normalised vectors (BGE, OpenAI `text-embedding-3-*`, most modern open models) work natively because cosine collapses to L2 on the unit sphere. Inner-product PQ for non-normalised vectors is a separate problem.

## Try it

```
$ cargo install heliosdb-nano --version 3.32.1 --features vector-persist
$ heliosdb-nano start --data-dir ./data
HeliosDB Nano v3.32.1 listening on 127.0.0.1:5432 (PG) and 127.0.0.1:3307 (MySQL)
```

Connect with `psql` from there. The how-to in [Build a RAG App on Nano v3.32](https://www.heliosdb.com/blog/rag-app-on-nano-3-32-in-80-lines-of-rust.html) walks through the Rust-side path for the persistent index. The [comparisons page](https://www.heliosdb.com/comparisons.html) has the side-by-side feature matrix.

HeliosDB Nano is Apache 2.0. Repository: [github.com/dimensigon/HDB-HeliosDB-Nano](https://github.com/dimensigon/HDB-HeliosDB-Nano).