gibram-io

gibram

Go2026–2026

gibram-io / gibram

gibram

GibRAM is an in-memory knowledge graph server designed for retrieval augmented generation (RAG / GraphRAG) workflows.

Explore on GitHub Read Hacker News discussions

2Distinct people

4Mentions

0Explicit recommenders

107GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

GibRAM is an in-memory knowledge graph server designed for retrieval augmented generation (RAG / GraphRAG) workflows.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by hour4 dated mentions

Observed mentions: 2026-01-18 06:47:17 UTC to 2026-01-18 16:59:34 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
Jan 18, 06:00	2026-01-18 06:00:00 UTC	2026-01-18 07:00:00 UTC	1	1	0
Jan 18, 07:00	2026-01-18 07:00:00 UTC	2026-01-18 08:00:00 UTC	1	0	1
Jan 18, 08:00	2026-01-18 08:00:00 UTC	2026-01-18 09:00:00 UTC	0	0	0
Jan 18, 09:00	2026-01-18 09:00:00 UTC	2026-01-18 10:00:00 UTC	0	0	0
Jan 18, 10:00	2026-01-18 10:00:00 UTC	2026-01-18 11:00:00 UTC	0	0	0
Jan 18, 11:00	2026-01-18 11:00:00 UTC	2026-01-18 12:00:00 UTC	0	0	0
Jan 18, 12:00	2026-01-18 12:00:00 UTC	2026-01-18 13:00:00 UTC	0	0	0
Jan 18, 13:00	2026-01-18 13:00:00 UTC	2026-01-18 14:00:00 UTC	0	0	0
Jan 18, 14:00	2026-01-18 14:00:00 UTC	2026-01-18 15:00:00 UTC	0	0	0
Jan 18, 15:00	2026-01-18 15:00:00 UTC	2026-01-18 16:00:00 UTC	0	0	0
Jan 18, 16:00	2026-01-18 16:00:00 UTC	2026-01-18 17:00:00 UTC	2	0	2

What Hacker News says

4 sources

ktyptorio·Jan 18, 2026

There are two steps: Vector search (HNSW): Find top-k similar entities/text units from the query embedding Graph traversal (BFS): From those seed entities, traverse relationships (up to 2 hops by default) to find connected entities This catches both semantically similar entities AND structurally related ones that might not match the query text. Implementation: https://github.com/gibram-io/gibram/blob/main/pkg/engine/eng...

In Show HN: GibRAM an in-memory ephemeral GraphRAG runtime for retrieval

threecheese·Jan 18, 2026

Appears to be: https://github.com/gibram-io/gibram/blob/main/sdk/python/gib...

In Show HN: GibRAM an in-memory ephemeral GraphRAG runtime for retrieval

ktyptorio·Jan 18, 2026

I've just released a casual personal project for Ephemeral GraphRAG. It's still experimental and open source: https://github.com/gibram-io/gibram

In Ask HN: How are you doing RAG locally?

ktyptorio·Jan 18, 2026Submission

Show HN: GibRAM an in-memory ephemeral GraphRAG runtime for retrieval

Hi HN, I have been working with regulation-heavy documents lately, and one thing kept bothering me. Flat RAG pipelines often fail to retrieve related articles together, even when they are clearly connected through references, definitions, or clauses. After trying several RAG setups, I subjectively felt that GraphRAG was a better mental model for this kind of data. The Microsoft GraphRAG paper and reference implementation were helpful starting points. However, in practice, I found one recurring friction point: graph storage and vector indexing are usually handled by separate systems, which felt unnecessarily heavy for short-lived analysis tasks. To explore this tradeoff, I built GibRAM (Graph in-buffer Retrieval and Associative Memory). It is an experimental, in-memory GraphRAG runtime where entities, relationships, text units, and embeddi

Read the rest

ngs live side by side in a single process. GibRAM is intentionally ephemeral. It is designed for exploratory tasks like summarization or conversational querying over a bounded document set. Data lives in memory, scoped by session, and is automatically cleaned up via TTL. There are no durability guarantees, and recomputation is considered cheaper than persistence for the intended use cases. This is not a database and not a production-ready system. It is a casual project, largely vibe-coded, meant to explore what GraphRAG looks like when memory is the primary constraint instead of storage. Technical debt exists, and many tradeoffs are explicit. The project is open source, and I would really appreciate feedback, especially from people working on RAG, search infrastructure, or graph-based retrieval. GitHub: https://github.com/gibram-io/gibram Happy to answer questions or hear why this approach might be flawed.

60 points · Open discussion