Show HN: Instant GraphRAG over any Postgres database | Hacker News Reader

Show HN: Instant GraphRAG over any Postgres database

polygres.com

5 pointsdaleverett4 comments

What are the memory requirements for pgGraph like? Does the entire graph for my dataset need to fit in memory?

You can try it out, whats in memory is a compressed mathematical map of your data, typically it uses about 30-34x less memory than the total dataset size. Currently the only ram hungry part is during the graph build (which we're working on lowering too.)

The wikipedia demo is cool, try it out!

Hi HN, I’m Dale. I’m building Polygres with my twin brother and a longtime friend who is a decade older than us lol.

Polygres is an all in one Postgres-based database that combines relational data, graph traversal, vector search, full-text search, and reranking over the same source-of-truth data.

We built this because we kept seeing devs building RAG or agent systems having to sync the same data across several stores: Postgres for application data, Qdrant or Pinecone for vectors, Neo4j for graph traversal, and then a lot of glue code to keep everything consistent. That adds operational complexity, stale-index problems, and awkward retrieval logic.

Polygres is our attempt to keep more of that inside Postgres.

You can insert and update data with normal SQL, represent relationships as a graph (with a real graph engine not pushdown queries), and run graph traversal, semantic search, text search, hybrid retrieval, and ranking in one place.

If Postgres is already your system of record, we want to make it possible to avoid maintaining separate source-of-truth, vector, and graph databases unless you really need to.

pgvector covers the vector side, but we wanted the missing graph component too, so we built pgGraph as an open-source Postgres extension: https://github.com/Evokoa/pgGraph

For this HN launch, we built a public Simple English Wikipedia demo as a retrieval test surface: https://polygres.com/wikipedia

The demo does not generate answers with an LLM; it is meant to show the retrieval layer itself.

I’d love feedback on whether keeping graph and vector retrieval inside Postgres is useful for your workflows, what APIs or query patterns you would expect from something like this, and whether the Wikipedia demo makes the retrieval behavior clear.

I’m also curious how people here feel about pgvector in production. We’ve heard mixed feedback, especially around scale, and are trying to understand whether the right path is to build around it, contribute to it, or eventually replace parts of the vector layer ourselves.

Happy to answer technical questions, and very open to criticism.

Reply on news.ycombinator.com