TypeGraph – Type-safe graphs on Postgres/SQLite (no graph DB required)
Hi HN, I built TypeGraph, a type-safe knowledge graph library that runs on your existing Postgres or SQLite. After years of building knowledge graphs and other graphy things, I had the same issues whenever an application’s relationship modeling (permissions, RAG context, recommendations) outgrew standard ORMs: deploy a dedicated graph database (heavy ops, separate infra, data syncing headaches), or roll a graph-in-SQL implementation by hand. I've hand-rolled enough of these to know the drill: same table structures, same traversal boilerplate, same performance surprises. I wanted graph…
What it does
In the maker’s words, at launch
Hi HN, I built TypeGraph, a type-safe knowledge graph library that runs on your existing Postgres or SQLite. After years of building knowledge graphs and other graphy things, I had the same issues whenever an application’s relationship modeling (permissions, RAG context, recommendations) outgrew standard ORMs: deploy a dedicated graph database (heavy ops, separate infra, data syncing headaches), or roll a graph-in-SQL implementation by hand. I've hand-rolled enough of these to know the drill: same table structures, same traversal boilerplate, same performance surprises. I wanted graph semantics without graph infrastructure so I built TypeGraph as that pattern packaged as a library. It runs on anything from in-memory SQLite to a full Postgres cluster, using Zod for a single source of truth (driving your DB schema, API validation, and TS types). You query it with a fluent builder that's fully typed through traversals: const results = await store .query() .from("Person", "p") .traverse("worksAt", "e") .to("Company", "c") .whereNode("c", (c) => c.industry.eq("Tech")) .select((ctx) => ({ person: ctx.p.name, company: ctx.c.name, role: ctx.e.role, })) .execute(); Eject at any time and you're left with clean, well-structured SQL tables and nothing proprietary to untangle. A few things that set it apart from rolling your own: * Ontology reasoning: subClassOf, implies, inverseOf — query for "Media" and automatically get Podcasts and Articles. Define "Admin implies Editor" and permission checks expand automatically. * Vector + graph queries: combine embedding similarity search with graph traversal in one query. Uses pgvector on Postgres, sqlite-vec on SQLite. * Incremental adoption: builds on Drizzle. Add graph capabilities to an existing project without replacing your ORM or migrating your database. Where it works well: knowledge graphs for RAG (vector similarity + graph context), relationship-based access control, recommendations, social features, any domain where multi-hop relationships are core. Where it doesn't: billions of edges (use a graph database), heavy graph algorithms like PageRank (use specialized tools), distributed graph processing. Docs: https://typegraph.dev GitHub: https://github.com/nicia-ai/typegraph/ Happy to answer questions about the design, implementation, or tradeoffs.
Does the same job
all alternatives →- CNCozo – new Graph DB with Datalog, embedded like SQLite2022 · github.com · ▲425
Hi HN, I have been making this Cozo database since half a year ago, and now it is ready for public release. My initial motivation is that I want a graph database. Lightweight and easy to use, like SQLite. Powerful and performant, like Postgres. I found none of the existing solutions good enough. Deciding to roll my own, I need to choose a query language. I am familiar with Cypher but consider it not much of an improvement over CTE in SQL (Cypher is sometimes notationally more convenient, but not more expressive). I like Gremlin but would prefer something more declarative. Experimentations…
- GFGraphQL for Postgres2015 · github.com · ▲195
- HOHelixDB – Open-source vector-graph database for AI applications (Rust)2025 · github.com · ▲237
Hey HN, we want to share HelixDB (https://github.com/HelixDB/helix-db/), a project a college friend and I are working on. It’s a new database that natively intertwines graph and vector types, without sacrificing performance. It’s written in Rust and our initial focus is on supporting RAG. Here’s a video runthrough: https://screen.studio/share/szgQu3yq. Why a hybrid? Vector databases are useful for similarity queries, while graph databases are useful for relationship queries. Each stores data in a way that’s best for its main type of query (e.g.…
- ASA SQL database implemented purely in TypeScript type annotations2020 · github.com · ▲426
LatticeDB – Like SQLite but for graph databases12d ago · github.com · ▲190We have been using graph DBs more and more at work. I found them painful to work with locally and decided to try and build something better.
- SGSimple-graph – a graph database in SQLite2020 · github.com · ▲237
More ai this month
the category →
I trained a 125M-parameter transformer to autocomplete piano performances in real time (~108 notes/sec on an iPhone 15). The idea is basically GitHub Copilot or Tabnine, except instead of prompting it with code, you prompt it by playing a few notes on a MIDI piano. The model then continues what you played, entirely on-device. The app is free if anyone wants to try it. Happy to answer questions about the model, training, Core ML, or the many things that didn't work.
AI · 17d ago · simedw.com
Astute▲585Automate your B2B brand going viral, with new media creators
AI · 18d ago · company-app.joinastute.com
Hey HN, Henry from Cactus here! We previously released Cactus Needle, a 14MB agentic LLM for tool call, device use, and structured extraction for phones, wearables, smart homes, small robots and microcontrollers. We got really great feedback here, and have now incorporated the suggestions to release Needle 2. The whole model is a single 14MB binary that runs a full session in 28MB of RAM; 45m parameters at 2bit compression. Needle hits 500 tokens/sec decode speed on a Raspberry Pi 5, sits between 400-1,500 tokens/sec on VR devices like Meta Quest 3S and Apple Vision Pro, and ranges…
AI · 27d ago · cactuscompute.com
