PaperlayerView exact revision on arXiv

Source-linked AI summary

post-graph-rag: A PostgreSQL-Native Graph RAG Engine

Chandan Rajah

arXiv:2608.24921v1cs.AI

TL;DR

Graph RAG must connect facts across passages while managing infrastructure, extraction quality, and changing information over time. post-graph-rag addresses these problems in PostgreSQL with guarded extraction, canonical entities, and temporal relations; against LightRAG, it produces denser, more queryable graphs with lower latency and comparable answer quality, while enabling supersession measurements absent from the baseline.

  • Problem

    Graph RAG deployments require multiple stores and can create fragmented or unsupported graph structure when retrieval and extraction do not connect or validate facts.

  • Method

    post-graph-rag stores embeddings, entity graphs, and summaries in PostgreSQL while validating predicates, resolving aliases, normalising vocabulary, and tracking temporal and negated relations.

  • Results

    Under identical extraction and embedding models, post-graph-rag yields a denser, more queryable graph with lower query latency and comparable answer quality than LightRAG, while producing supersessions where the baseline produces none.

  • Takeaways & Limitations

    The measured gains come from treating extraction output as untrusted input and applying mechanisms that improve recall, entity consolidation, duplicate handling, and predicate queryability.

  • Takeaways & Limitations

    The evaluation reports structural and retrieval measurements rather than reference-answer scores, and each configuration was indexed only once despite stochastic extraction.

Abstract

from arXiv · show

Graph-based retrieval-augmented generation connects facts that no single passage states, but current implementations pay for that three times: in infrastructure, requiring a vector store, graph database and document store to be kept consistent; in graph quality, because an extraction pipeline that never refuses output fills the graph with edges that assert nothing; and over time, because a graph that only accumulates treats superseded and current facts alike. post-graph-rag is an open-source engine addressing all three. Text chunks with embeddings, a canonical entity graph and community summaries live in one PostgreSQL database, with pgvector for search and edge tables for traversal. Extraction-time invariants run before anything is written: vague predicates, pronominal names and bare quantities are rejected; predicates are normalised onto an optional vocabulary; entities resolve to one vertex per canonical name via model-supplied aliases; and denied relations keep the positive predicate under a negation flag. A temporal layer lets relations carry a validity period from the prose, lets a later document supersede an earlier incompatible assertion from document order alone, and answers as-of queries. Against LightRAG on three corpora under identical extraction and embedding models, post-graph-rag builds a denser graph everywhere, up to $2.4\times$ the relations per entity, and a more queryable one: distinct edge labels run at 0.46 to 0.58 per relation, 0.11 under a controlled vocabulary, against 0.77 to 1.33. It answers comparably with lower query latency, and supports temporal evolution the baseline lacks: 13 and 8 relationships superseded on a novel sequence and a decade of filings, against zero. These are engineering measurements, not a benchmark result. Code: https://github.com/crajah/post-graph-rag, https://github.com/crajah/post-graph

1 Introduction

Graph RAG addresses multi-passage and corpus-level retrieval gaps, but routine deployment is constrained by infrastructure, extraction-quality, and temporal-consistency costs. post-graph-rag combines a PostgreSQL-native architecture with extraction invariants, temporal handling, and retrieval mechanisms, evaluated against LightRAG under controlled models.

  • Similarity-ranked passage retrieval cannot retrieve answers requiring facts from separate, lexically dissimilar passages.
  • Infrastructure: Typical Graph RAG deployments require vector, graph, and document stores to remain consistent under partial failure.
  • Time: Accumulating graphs conflate current and superseded facts, producing contradictory answers when corpus facts change over time.
  • Approach: post-graph-rag co-locates passages, a canonical graph, and community summaries in PostgreSQL while adding fail-closed extraction gates and temporal supersession.
  • Evaluation: The evaluation compares extraction and embedding models directly against LightRAG on three corpora and explicitly treats the results as engineering measurements, not benchmark results.

2 Related Work

Prior work establishes passage, graph-based, temporal, and PostgreSQL approaches that motivate post-graph-rag. The paper positions its combination of document-order supersession and optional prose-derived validity intervals as novel among the cited Graph RAG systems.

  • Retrieval-augmented generation: RAG surveys and analyses identify multi-hop and corpus-level questions as systematic weaknesses of passage retrieval.
  • Graph-based RAG: Graph-based RAG extracts entities and relations, clusters the graph, summarizes communities, and answers global questions from those summaries.
  • LLMs as knowledge-graph constructors: LLM knowledge-graph research reports unstable predicates, unresolved coreference, and hallucinated co-occurrence relations motivating validation gates.
  • Time in databases and knowledge graphs: Temporal database work separates fact validity time from recording time, while prior temporal knowledge-graph work largely emphasizes representation learning.
  • Novelty: The paper claims that combining document-order supersession with optional prose-supplied validity intervals is not offered by the cited Graph RAG systems.

3 System Design

The system uses PostgreSQL tables for vectors, graph structure, documents, and summaries, with realm/space isolation and staged indexing, retrieval, and community construction. Its consistency safeguards favor correctness under concurrency and explicit failures over unrestricted indexing throughput or silent degradation.

  • System paths: Indexing extracts and validates chunk content, embeds chunks and entities, and writes vertices and edges; retrieval combines vector search, one-hop expansion, chunk expansion, summaries, and synthesis.
  • Data model: Vertex tables store HNSW-indexed embeddings, while edge tables store endpoints and JSONB payloads; relation embeddings are optional and off by default.
  • Tenancy: Entities are unique within each realm and space, and traversal is space-scoped as well as vector search to prevent cross-space fact leakage.
  • Indexing: Batch extraction and embedding run concurrently, but graph writes remain ordered so concurrent entity resolution converges on one vertex.
  • Trade-offs: Serialised writes reduce indexing throughput relative to unrestricted parallelism, a cost the paper leaves unquantified in its comparison.
  • Failure handling: Missing vector support, unusable extraction, and embedding failures raise or fail closed rather than silently producing empty or incomparable retrieval structures.

4 Extraction

Extraction combines overlapping chunks, threaded document context, optional gleaning, and deterministic rejection gates. Prompt constraints and normalization then improve entity stability, predicate queryability, provenance, and explicit handling of denied relations.

  • Chunking and context: Overlapping chunks preserve relations whose subject and object fall across chunk boundaries, while document context supplies canonical names for resolving references.
  • Gleaning: Gleaning adds a second extraction pass for missed entities and triples, increasing relations by 40% and entities by 11% at one extra LLM call per chunk.
  • Validation gates: Validation gates reject records that cannot form well-formed assertions, especially vague predicates that would turn mere co-occurrence into graph edges.
  • Entity granularity: Stable-entity prompting prevents filing-specific vertices, and affected-question retrieval recall rose between 2× and 9%.
  • Normalization and resolution: Predicate normalization, controlled-vocabulary snapping, and aliases reduce lexical fragmentation across relations and entities.
  • Resolution and corroboration: Canonical entity resolution makes repeated mentions one vertex, while provenance counts distinct contributing chunks rather than duplicate writes.
  • Negation: Denied relations retain their positive predicate with a negated flag so traversal and summaries can represent denials explicitly.

5 The Temporal Model

The temporal model records stated validity periods, resolves incompatible assertions by document order, and supports as-of retrieval while preserving historical edges and entities.

  • Validity periods: Validity intervals are stored only when prose states a period; vague dates are discarded, and partial dates are padded for comparison.Undated relations remain valid at every point in time.
  • Supersession: Supersession marks an earlier relation as superseded when a newer relation in the same exclusive predicate group targets the same ordered pair.Exclusive groups are deployment-defined, such as ally_of versus enemy_of.
  • Supersession: Document order, rather than model-supplied dates, determines which incompatible assertion wins, while superseded edges remain available as history.Documents use caller-supplied order, such as publication order or fiscal year.
  • As-of retrieval: As-of retrieval filters relations by validity date, excludes superseded relations by default, and can include them when explicitly requested.Undated relations always match the as_of filter, and the two filters compose.
  • Re-indexing: Re-indexing uses stable document keys and content hashes to avoid duplicate unchanged chunks and replace changed document contributions.Removed contributions are re-extracted rather than appended.
  • Re-indexing: Entities losing their last document mention become dormant rather than deleted, and can be revived by later mentions; dormancy is independent of supersession.Superseded relations still evidence that their endpoints exist.

6 Communities

Communities turn clustered entity subgraphs into traceable reports for corpus-level questions, with ranking and rebuild rules designed to keep summaries useful and current.

  • Community construction: Corpus-level questions are answered from summaries of clustered subgraphs rather than retrieved passages.The graph is weighted by corroboration and denial status before Leiden clustering, with deterministic label propagation as fallback.
  • Community reports: Each surviving cluster becomes an embedded report containing entities, internal relations, findings, and an importance rating, with edges back to its members.Denied relations are rendered as denials and not as holding facts.
  • Community retrieval: Community reports are ranked using similarity, importance rating, and cluster size because pure similarity can favor a narrow niche cluster over a broad thematic one.The observed failure involved a steampunk alternate-histories cluster for a main-themes query.
  • Community maintenance: A community build clears and regenerates derived reports, warning when the oldest report predates the latest graph write.This prevents stale clusters from silently describing a changed graph.
  • Community maintenance: Reports are processed largest first, unusable reports are skipped, duplicate titles are qualified, and global retrieval falls back to relation ranking when communities are absent.These rules preserve partial coverage and avoid hard failure.

7 Retrieval and Synthesis

Retrieval combines conditioned keyword search, entity traversal, mention expansion, and optional direct relation search before synthesising evidence under explicit quotas and filters.

  • Retrieval modes: Unknown retrieval modes raise an error, while the default mix mode combines the system’s available evidence sources.The bypass mode performs no retrieval for conversational turns routed through the same interface.
  • Query conditioning: Dual-level keywords use concrete entities to sharpen entity search and themes to steer global relation ranking.Keyword extraction may use a lexical fallback because the keywords are not persisted.
  • Candidate expansion: Retrieval seeds entities and documents with vector search, expands up to k hops through scoped graph traversal, and pulls chunks linked by entity mentions.Mention expansion reaches explanatory passages that may share none of the question’s wording.
  • Candidate expansion: Traversal applies temporal and relation-type restrictions within the walk, preventing paths from crossing superseded or out-of-period edges.Post-filtering would allow invalid edges to influence which vertices are reached.
  • Ranking: Traversal candidates are ordered nearest-hop first, then by assertion recency, while global candidates use keyword overlap with corroboration as a tie-break.This hop-major ordering protects nearby evidence under token truncation.
  • Ranking: 67.8% to 67.5%: reranking the same multi-hop candidate set by direct query–relation cosine similarity did not improve the on-topic share.Genericly named endpoints remain unreachable through traversal, so reranking cannot recover them.
  • Two-channel retrieval: Direct relation embeddings add a parallel similarity channel, and quota-based interleaving preserves both it and traversal in the truncated context.Pooling and sorting by one similarity score reproduced the similarity channel alone on all four evaluation questions.
  • Synthesis: The synthesis prompt allocates separate token shares to community reports, passages, entities, and relations, with community reports leading when available.Retrieved relations carry validity periods, and denied relations are rendered with an explicit NOT marker.

8 Evaluation

The evaluation isolates mechanism effects and compares post-graph-rag with LightRAG across three differently structured corpora under matched extraction and embedding settings, reporting structural and retrieval behavior rather than reference-scored answers.

  • Evaluation design: Three corpora test different settings: cross-document entity resolution in Wikipedia, reversing alliances across Dumas novels, and inverted relationships across Boeing filings.The corpora span approximately 127k, 645k, and 586,775 characters respectively.
  • Evaluation design: LightRAG comparisons hold extraction model, embedding model, gleaning depth, and chunk sizing identical across systems.Embeddings are text-embedding-3-small with 2000-character chunks and 200-character overlap.
  • Evaluation scope: The study reports graph-structural measurements and retrieval behavior rather than scored answer quality against a reference-answer set.This is an engineering evaluation rather than a benchmark result.
  • Mechanism effects: 40%: gleaning raises relation recall from 321 to 450 on Wikipedia at one extra LLM call per chunk, while entity count rises 11%.The mechanism-isolation experiment holds the extraction model fixed.
  • Mechanism effects: Six split vertices become zero, and duplicate edge rows fall from seven to zero, through alias resolution and corroboration weighting.Charles Babbage and Ada Lovelace absorb multiple surface forms.
  • Mechanism effects: The vocabulary changes queryability rather than relation count: designed (20), worked_with (18), built (17), and wrote (14) form the predicate head.Without the vocabulary, the commonest predicate appears six times.

8.3 Sensitivity to the extraction model

Extraction-model choice changes graph shape substantially: MiniMax favors graph richness, while gemma favors predicate queryability. With identical extraction and embedding settings, post-graph-rag is denser and faster to query than LightRAG, though indexing throughput is not directly comparable.

  • Model sensitivity: MiniMax-M2.7 builds the richest graph, while gemma-4-31B builds the most queryable graph.MiniMax emits the most entities and relations; gemma produces 44 distinct predicates at 94% vocabulary adherence, but stores 40% fewer relations.
  • Model sensitivity: 5.7× more aliases than Llama drives MiniMax-M2.7’s orphan count down to 26.The comparison holds corpus, settings, and clustering fixed while varying only the extraction model.
  • Model sensitivity: 44 distinct predicates at 94% vocabulary adherence characterize gemma-4-31B, versus 395 at 33% for MiniMax-M2.7.The models trade off vocabulary adherence against predicate diversity, while costs remain within 7% across the three stronger models.
  • LightRAG comparison: 82% more relations per unit of text are extracted by post-graph-rag than LightRAG on the Wikipedia comparison.The systems use the same extraction model, embedding model, gleaning depth, and equivalent chunk sizing.
  • LightRAG comparison: 57% unconstrained and 11% with the biography preset are post-graph-rag’s distinct edge-label shares, versus 460 labels across 421 LightRAG relations.Normalised predicates and controlled vocabulary make relation-type traversal and filtering meaningful.
  • LightRAG comparison: 2× faster global querying is reported for post-graph-rag, with comparable answer quality and inline citations that LightRAG lacks.The comparison covers both retrieval modes under the same corpus and model conditions.
  • Evaluation boundary: Indexing wall-clock is not directly compared because PostgreSQL transactional writes and LightRAG’s file-backed NetworkX backend provide different guarantees and concurrency limits.A wall-clock ratio would measure storage architecture as well as extraction and would change with a different LightRAG backend.

8.5 Corpora whose facts change

On corpora with changing facts, post-graph-rag uses document order and validity periods to close superseded relations and support as-of retrieval. Results also show that dense, well-granular extraction is necessary for temporal updates and retrieval quality.

  • Temporal evolution: Zero supersessions occurred in an earlier run sampling ∼5% of each novel.Supersession requires the same entity pair to recur, making density a precondition rather than a sufficient consequence of sparse sampling.
  • As-of retrieval: 22 →24 →25 relations are retrieved across Boeing as-of years 2006 →2024.A reduced_by relation for 777X deferred production costs surfaces only at as_of=2024, enabling a trajectory rather than a timeless definition.
  • Entity resolution: 729 Dumas entities carry aliases, but honorific-heavy fiction still leaves unresolved distinctions such as Monsieur d’Artagnan and D’Artagnan.The passage characterizes fiction as harder for entity resolution than Wikipedia.
  • Entity granularity: 2× to 9× higher retrieval recall followed constrained entity granularity on the Boeing corpus.The change also reduced %boeing% vertices from 54 to 37 and increased supersessions from 5 to 8.
  • Predicate vocabulary: 46% of relation count is covered by finance-preset labels, compared with ∼11% on biography.The finance preset contains 32 predicates and 8 exclusivity groups, reflecting the broader topic range of filings.

8.7 Traversal depth and the second retrieval channel

Traversal depth increases retrieved signal but also noise, while similarity weighting improves on-topic retrieval under truncation. No single quota dominates: traversal favors subject- or theme-named questions, whereas similarity favors chain questions.

  • Traversal depth: Three hops retrieves roughly three times as many on-topic relations but ten times as much noise as shallower traversal.Depth helps the Boeing chain question by connecting revenue decline, 737-9 grounding, and fixed-price development charges.
  • Second retrieval channel: At q = 0.5, enabling similarity retrieval raises on-topic share from 49% to 69% on gpt-oss-120b and from 66% to 88% on MiniMax-M2.7.At q = 1, the corresponding shares are 73% and 98%.
  • Second retrieval channel: The keyword-overlap metric is biased toward similarity retrieval because it correlates with the embedding similarity used by that channel.Answer-level judging was used instead to compare intermediate quotas.
  • Evaluation: Transposition controls discarded 18 of 50 judgements as position-determined rather than content-determined.A single-pass protocol would have counted these order effects as results.
  • Quota comparison: Traversal-weighted retrieval leads on subject- or theme-named questions, while similarity-weighted retrieval leads on chain questions and wins 5–0 on the weaker graph.The two graphs disagree in aggregate but agree after grouping questions by shape.

9 Limitations

The evaluation is limited by corpus and language scope, single-run stochastic extraction, confounded throughput comparisons, and several unresolved design dependencies. Structural and retrieval measurements are indicative rather than benchmark-level evidence.

  • Scope: The evaluation covers Wikipedia, nineteenth-century French fiction in translation, and US financial filings, all long-form English prose.The authors expect meaningfully different behavior on conversational transcripts, code, or corpora whose significant entities are not named-entity-like.
  • Scope: Predicate vocabularies are domain-specific by construction, although the underlying mechanism generalizes.A declared vocabulary therefore cannot be assumed to transfer unchanged across domains.
  • Evaluation evidence: Reference-answer scores are not reported, so the LightRAG comparison supports indicative structural and retrieval conclusions rather than a conclusive end-to-end answer-quality claim.The extraction model alone can move results enough to dominate system-level differences.
  • Evaluation evidence: Single-run configurations make smaller entity and relation-count differences susceptible to stochastic run-to-run variance.The authors defend large categorical effects rather than precise small differences.
  • Systems comparison: No indexing-throughput comparison against LightRAG is claimed because the systems provide different storage guarantees and the Boeing runs shared a router.The reported ratio would measure storage architecture as much as extraction pipeline.
  • Temporal scope: Supersession fires only for repeated entity pairs whose predicates belong to a declared exclusive group, so sparse or undeclared-vocabulary indexes produce none.The reported counts of 13 and 8 are relationships that genuinely reversed, not a large graph fraction.
  • Extraction scope: Fail-closed gates reject malformed structure but cannot detect capabilities omitted by an extraction model that never emits aliases or negation flags.Such a graph can remain internally consistent while quietly missing those capabilities.
  • Retrieval scope: Traversal uses fixed depth and edge budgets rather than relevance pruning, so precision still falls with depth.On one question, precision falls from 100% to 10%.

10 Conclusion

post-graph-rag consolidates Graph RAG storage in PostgreSQL, validates extraction before writing, and models temporal change through supersession. Across the reported engineering measurements, it produces denser, more queryable graphs with comparable answer quality and lower query latency than LightRAG, while extraction-model variation remains a major reproducibility concern.

  • Conclusion: post-graph-rag places embeddings, a canonical entity graph, mention edges, and community summaries in one PostgreSQL database.Tenancy uses schema-per-realm partitioning with uniform space scoping across search and traversal.
  • Conclusion: Treating extraction output as untrusted input yields denser, more queryable graphs, comparable answer quality, and lower query latency against LightRAG under identical extraction models.The measured trade-off is a one-off index-time cost for ordered graph writes.
  • Conclusion: Modelling validity and document-order supersession lets the graph answer trajectory questions that an accumulative graph cannot resolve.The baseline has no counterpart for this temporal capability.
  • Conclusion: Changing only the extraction model tripled alias emission, moved negation capture from zero to 21 relations, and moved vocabulary adherence from 33% to 94%.The authors therefore call for protocols that pin the extraction model when comparing Graph RAG systems.
  • Availability: The implementation and graph substrate are Apache 2.0 licensed and available on GitHub and PyPI.The evaluation harness and raw measurement notes are included in the repository.
Loading 2608.24921v1…