Daniel Kim

Posted on Aug 20

Polygres Says You Don't Need a Vector Database, a Graph Database, or a Memory Layer — Just Two Postgres Extensions

#postgres #opensource #database #ai

Every few weeks another Product Hunt launch promises to fix "AI memory." Most of them ship the same architecture: pull your data out of wherever it lives, push it into a purpose-built vector store, stand up a sync job to keep the copy fresh, and hope the copy never drifts from the source of truth. Mem0, Zep, and Letta all took that shape, and they disagree with each other mostly on policy — what to keep, what to forget, how to summarize. What none of them touched was the more boring possibility: that the "new database for AI context" step was never necessary in the first place.

That's the bet behind Polygres, a managed PostgreSQL service from a small team called Evokoa that launched on Product Hunt with the tagline "turn your entire database into a context window for AI." Strip away the marketing framing and the actual product is two open-source Postgres extensions — pgGraph and pgContext — plus a hosted layer around them. No new database. No ETL pipeline. No second system to keep in sync. The pitch is that your existing Postgres instance can do graph traversal, vector search, and hybrid retrieval natively, and that doing so in-place is not just simpler but measurably faster than shipping the same query to a dedicated store.

That's a strong, checkable claim, which is exactly what makes it worth digging into instead of skimming the landing page.

What Polygres actually is

Polygres itself is thin. It's a managed hosting layer — currently in a design-partner / early-access phase rather than generally available with public pricing — that runs pgGraph and pgContext for you and wraps them with the usual managed-Postgres conveniences (backups, connection pooling, a dashboard). If you want the interesting part, you don't need Polygres at all: both extensions are Apache-2.0 licensed and can be self-hosted for free, which is unusual restraint for a company whose product page leads with "AI."

pgGraph adds graph queries — traversal, shortest path, relationship search — on top of tables you already have, without a separate graph database or a new query language. It's written in Rust on the pgrx framework and ships as a real Postgres extension, not a foreign data wrapper bolted on the side. At the time of writing it carries over 1,000 GitHub stars, 86 forks, and 469 commits — meaningfully more traction than the typical week-old Product Hunt launch, which suggests the open-source project predates and is feeding the commercial one, not the reverse.

pgContext is the newer, smaller sibling (243 stars): a PostgreSQL 17/18 extension billed as "a full AI search engine, built into Postgres." It does dense vector search, metadata-filtered approximate search, and hybrid dense-plus-full-text retrieval, all inside the same tables and the same transaction boundary as the rest of your application data.

How it actually works

This is where the architecture gets more interesting than the tagline.

pgGraph doesn't turn Postgres into a graph database in the sense of replacing its storage engine. It compiles your relational foreign-key relationships into Compressed Sparse Row (CSR) edge stores — a layout built for O(1) adjacency lookups via contiguous array slices — and memory-maps the result as read-only .pggraph artifact files, one per backend process. Your relational tables stay the system of record; pgGraph builds a derived, rebuildable graph runtime next to them. That's a deliberate trade-off: you get traversal speed close to a dedicated graph engine, but the graph is a snapshot, not a live view. There's no real-time sync guarantee — if your underlying rows change, the graph index is stale until it's rebuilt. The project is upfront that unbounded traversal is a real failure mode and ships circuit breakers — depth limits, visited-node tracking, frontier limits — specifically to stop a bad query from taking down the database.

pgContext takes a different approach to the same "stay inside Postgres" principle. Instead of an external index that gets queried and then joined back to Postgres for the real data (the standard pattern with an external vector database), it persists a page-native HNSW index directly on Postgres index pages, and — this is the part competitors mostly skip — re-scores every approximate result exactly against the live row before returning it. That means every answer inherits Postgres's actual MVCC visibility, row-level security, and SQL predicates, rather than a best-effort copy that might be a write behind or blind to a permissions change. Metadata filtering is pushed through the persisted HNSW graph itself ("filter-aware ANN, not post-filtering," in the project's own words) rather than bolted on afterward, and hybrid retrieval — combining vector similarity with Postgres full-text ranking via reciprocal-rank fusion — ships as a built-in SQL function, not application-layer glue code you write yourself.

The headline number: on the GloVe-100-angular benchmark (1.18M vectors, cosine distance), pgContext reports matching pgvector's recall while answering 3.8–5.3x faster — 0.910 recall@10 at 2.4ms versus pgvector's 2.5ms delivering only 0.75 recall@10 at a comparable setting. That's a genuinely large gap if it holds outside one benchmark on one dataset, and it's the number every claim in the launch materials ultimately rests on.

Concretely, using pgContext looks like registering a column for filtering and then querying with SQL rather than a client SDK — something like CREATE EXTENSION pgcontext; followed by a hybrid search call that takes a query embedding, a text query for full-text ranking, and a metadata filter in one statement, with reciprocal-rank fusion happening inside the function rather than in your application code. That's the practical DX difference from a typical vector-database SDK: there's no separate client library version to pin, no separate connection pool, and no risk of the vector query and the row fetch executing against two different points in time. On the pgGraph side, the equivalent is a traversal function called from SQL — shortest-path or neighborhood queries against tables you already have foreign keys on — bounded by the circuit breakers (max depth, max frontier size, visited-node caps) so a runaway recursive traversal degrades to an error instead of an out-of-memory event on a shared production instance.

What actually changed versus what came before

Three existing options, and how Polygres's approach differs from each:

pgvector inside plain Postgres. This is the honest baseline, and the README implicitly concedes it: if you just need similarity search over documents, pgvector on any Postgres install does that, no extra extension required. Polygres's argument is narrower than "vector search in Postgres is new" — it's "our vector search in Postgres is faster than the vector search in Postgres you already have," plus a graph layer pgvector never attempted.

Dedicated vector databases (Pinecone and similar). These solve a different problem — massive scale, purpose-built infra, managed ops for enormous embedding volumes — at the cost of a second system, a sync pipeline, and a network hop between "find the match" and "fetch the row." For teams whose AI features are additive to an existing Postgres-backed app rather than the entire product, that second system is often pure overhead: another vendor bill, another place data can drift, another access-control surface to audit separately from the one Postgres already enforces.

The agent-memory layer category (Mem0, Zep, Letta). These products solve a genuinely different problem — deciding what an agent should remember, forget, or summarize across sessions — and they still need somewhere to persist that memory, typically their own store or an integration into one of the above. Polygres doesn't compete with that decision layer at all; it's a plausible foundation underneath one, if a team ever built a memory abstraction that just wrote to Postgres instead of a bespoke store.

Managed Postgres platforms (Supabase, Neon). Both already bundle pgvector and are excellent general-purpose managed Postgres — Supabase around $25/month for Pro plus usage, Neon usage-based with roughly a $15/month representative spend on its Launch tier — but neither ships graph traversal or the hybrid/filter-aware retrieval pgContext adds. Polygres doesn't attempt Supabase's auth, storage, and realtime bundle; it's a narrower, deeper bet on the retrieval layer specifically. Practically, that means Supabase or Neon plus self-hosted pgGraph/pgContext is a perfectly viable combination today — you don't need to wait for or adopt Polygres-the-company to get the extensions' benefits on a managed instance, as long as your provider allows installing community extensions, which is worth checking before assuming compatibility.

It's also worth placing this next to the broader "serverless Postgres platform" wave — companies like Xata, which open-sourced its core platform while keeping the profitable managed layer closed. Evokoa's split is structurally similar (open extensions, closed-for-now managed hosting) but narrower in scope: Xata is a full backend-as-a-service around Postgres, where pgGraph and pgContext are two specific capabilities you can bolt onto any Postgres you already run, managed by Evokoa or not.

Why developers should actually care

Cost. The self-hosted path is free and Apache-2.0, full stop. That's the strongest part of the pitch: you can add pgGraph and pgContext to a Postgres instance you already run and pay nothing beyond your existing hosting bill. The managed Polygres product, by contrast, has no public pricing yet — it's explicitly in a design-partner phase, reachable via email rather than a checkout page. If you were hoping for an apples-to-apples cost comparison against Supabase or a dedicated vector DB today, that comparison doesn't exist yet.

Latency. The 3.8–5.3x number is real if you trust a single self-reported benchmark on one open dataset. It hasn't been independently reproduced as far as this research turned up, and GloVe-100 is a convenient, well-understood dataset precisely because it's small and clean — production embedding workloads with higher dimensionality, filtered queries, and concurrent writes are a different test. Worth benchmarking yourself before betting a migration on it.

Developer experience. This is arguably the real selling point, more than raw speed: no new query language, no ORM adapter for a second database, no ETL job to babysit, no "which system is the source of truth right now" debugging session at 2am. If your AI feature reads from data that's already relational — user records, orders, support tickets, org structures — querying it in place is a meaningfully smaller surface area than standing up parallel infrastructure.

Security. Because pgContext re-checks results against live rows, your existing row-level security and access-control policies apply to AI-retrieved results automatically. That's not a minor detail — a lot of "add a vector database" projects quietly create a second, less-audited path to data that bypasses whatever permission model the primary database enforces. Keeping retrieval inside Postgres closes that gap by construction rather than by policy.

Lock-in. Apache-2.0 on both extensions is the opposite of a bait-and-switch open-core play, at least on paper. You can self-host the whole retrieval stack indefinitely without ever touching Polygres the company. The obvious risk with any young, VC-adjacent infra project is what happens to the license and roadmap once the managed product needs to make money — a pattern several other Postgres-platform companies have followed by open-sourcing the engine and keeping the profitable operational tooling closed.

Practical use cases

RAG over data you already have, without exporting it: support tickets, product catalogs, internal docs stored as Postgres rows, searched with the same transaction and permission boundary as everything else in the app. No nightly job pushing embeddings to a second store, and no window where a row was deleted in Postgres but still answerable from a stale vector index.
GraphRAG for relationship-heavy domains — org charts, fraud/anomaly detection over transaction graphs, recommendation paths, dependency graphs between internal services or documents — where the interesting signal is connections between rows, not just similarity between embeddings, and standing up a dedicated graph database (Neo4j-class infrastructure, a new query language, a new ops burden) for one feature is hard to justify against the size of the actual need.
Agent context that needs to respect access control: an internal support or ops tool where different users should see different retrieved results based on existing row-level security, without re-implementing that logic as a second, easy-to-forget filter in application code sitting in front of a vector database that has no concept of your permission model.
Hybrid search for product or documentation search, where pure vector similarity misses exact-keyword queries (SKUs, error codes, product names) and pure full-text misses semantic paraphrases — the reciprocal-rank fusion approach handles both without maintaining two separate search backends.
Incremental adoption inside an existing app. Because this is a normal Postgres extension rather than a new service, a team can add pgContext to one feature, measure it against pgvector on real traffic, and roll it back with DROP EXTENSION if it doesn't pan out — a much lower-commitment experiment than provisioning and populating a dedicated vector database first.

What the launch page leaves out

A few things worth knowing before adopting this, none of them fatal but all of them real:

Version lock-in on the newest Postgres. pgContext requires Postgres 17 or 18. If you're running 14–16 in production — extremely common — you can't adopt it without an upgrade project first. pgGraph is more permissive (14–18, with 13 deprecated post-EOL), but the two extensions don't share a version floor.
Experimental vector types. halfvec, sparsevec, and bitvec support is explicitly marked "partial, experimental" in the README, as is the IVFFlat index type. If your workload needs those specifically, you're on the leading, less-tested edge of the project.
The graph is a snapshot, not a live view. pgGraph's read-only, memory-mapped artifact model means graph queries can run against stale relationship data until the derived index is rebuilt. For workloads with rapidly changing relationships, that staleness window matters and isn't discussed in the marketing copy.
One benchmark, one dataset. The 3.8–5.3x speedup is real as reported, but it's a single vendor-run benchmark on a single well-known dataset. It's a reasonable signal, not independent verification.
The graph and search engines aren't unified yet. pgGraph and pgContext are sister projects; combined GraphRAG queries that use both in one pass are explicitly future work, not shipped today, despite Polygres's own tagline implying an integrated context layer.
No public pricing for the thing being launched. The Product Hunt launch is for Polygres, the managed product — but that product doesn't have a price yet. Everything genuinely usable today is the free, self-hosted open-source layer underneath it.

An independent read

The strongest part of this launch isn't the benchmark number, it's the restraint: a company that could have built "yet another vector database" instead built two narrow Postgres extensions and open-sourced both of them before monetizing anything. That's a healthier starting posture than most AI-infrastructure launches this year, and the 1,000+ stars on pgGraph suggest real developer pull rather than launch-day vote trading.

The weaker part is that the actual commercial product — the thing with a Product Hunt page and a launch story — is the least proven piece of the whole stack. The extensions have real adoption; the managed service is a design-partner waitlist with no price. Anyone evaluating this today is really evaluating pgGraph and pgContext as self-hosted open-source software, not Polygres as a managed offering, and should treat it that way rather than getting pulled in by launch-week framing that implies a finished, GA product.

The category-level argument — that AI context doesn't need a new database, just better use of the one you have — is genuinely under-explored compared to how much attention the "AI memory layer" space has gotten. It won't replace Pinecone-scale deployments or the deliberate forgetting policies Mem0/Zep/Letta are built around, and it shouldn't try to. But for the large number of teams whose "AI feature" is really "search over data that was already in Postgres," it's a much shorter path than most of what got funded this year.

Who should try it, wait, or skip it

Try it now if you're already on Postgres 17/18, your AI feature reads relational or graph-shaped data you already store there, and you're comfortable running community-maintained extensions in production. Self-hosting costs nothing but engineering time to evaluate.

Wait if you need the managed product specifically — there's no price and no GA date, so budgeting around it today is guesswork — or if your workload leans on the experimental vector types (sparsevec, bitvec, IVFFlat) that aren't fully baked yet.

Skip it if you're already deep into a dedicated vector database at real scale and migration cost outweighs a theoretical latency win you haven't verified against your own data, or if what you actually need is an opinionated agent-memory policy layer (summarization, forgetting, session scoping) rather than a faster retrieval engine underneath one.

Either way, the more durable story here isn't one product — it's the question it raises for the rest of the AI-infra market: how much of the "new database for AI" wave was solving a real technical limitation, and how much was skipping the less exciting work of making Postgres do it well?

Discussion: if you've put pgvector, a dedicated vector database, and a graph database in front of the same Postgres-backed app, which piece actually caused you the most operational pain — the sync jobs, the permissions drift, the query latency, or something else entirely?

Sources:

DEV Community