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.
daleverett•7h ago
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.