Show HN: BlitzGraph – Supabase for graphs, built for LLM agents

// what makes it different

Model reality, not tables.

Entities with multiple kinds. Relationships that traverse both ways. A typed JSON query language your agent composes correctly.

BlitzGraph only

⬡

Multi-kind entities

A User can also be an Admin and a Moderator, simultaneously. No role tables, no migrations. Entities evolve by gaining and losing kinds over time.

BlitzGraph only

⟲

Bidirectional relationships

"Who wrote this post?" and "What did this user write?" Same cost, same index, O(1) both ways. No reverse-lookup tables, no extra queries.

BlitzGraph only

⬚

Typed JSON queries (BQL)

Your agent composes query objects, not SQL strings. Filters, nested expands, projections, and full-text search in one request. Zero N+1.

⌥

Rich content types

EMAIL, URL, DATE, JSON, FLEX. Not just varchar. Built-in validation at the database level. Your schema describes what the data actually is.

⟷

Referential integrity

Cardinality constraints and onDelete policies (cascade, restrict, unlink) enforced at the engine level. Your graph stays consistent by default.

∿

Built-in full-text search

Native BM25 engine with typeahead, prefix, exact, and all-stems modes. No Elasticsearch, no external service. Works inside graph traversals.

⊕

Smart transactions

Mutations are topologically sorted and validated on the final result, not line by line. Business rules check the end state of the whole transaction, so complex multi-entity operations just work. All or nothing, always consistent.

⌂

Business logic in the database

Validations, computed fields, transforms, and effects, all defined in the schema. Your business rules live where the data lives, not scattered across middleware and app code.

// bql · blitz query language

The query language agents actually write correctly.

SQL forces agents to generate strings and guess result shapes. PostgREST adds a REST layer on top of tables. BQL is structured data from client to engine.

01

Compose queries from code, not strings.Agents and app code build typed JSON objects, not SQL strings, not ORM chains. The query IS the data structure. No generation step, no parsing ambiguity.

02

GraphQL-like reads, as typed JSON.Fetch a root entity, expand relationships, project nested fields, all in one request. Same filter, sort, and limit shape at every depth. Like GraphQL, but without the schema ceremony.

03

Model reality, not tables.Multi-kind entities, bidirectional arcs, and native $expand. Your data model mirrors how things actually relate. No join tables, no foreign key gymnastics.

04

Filter through relationships.Query by connected data, not just local fields. Traverse sessions, memories, owners, without stitching joins in application code.

BQL · polymorphic search

// Units that are both Human AND Spanish. Search + computed fields. { "$kinds": { "$all": ["Human", "Spanish"] }, "$search": "senior backend rust", "$filter": { "role": { "$in": ["engineer", "designer"] } }, "$fields": [ "name", "salary", "bonus", { "%total": { "$js": "salary + bonus" } }, { "$expand": "projects", "$sort": "-budget", "$limit": 3, "$fields": ["title", "budget", "spent", { "%remaining": { "$js": "budget - spent" } } ] } ] }

BQL · agent memory traversal

// Recent sessions with arc metadata on high-relevance memories. { "$kinds": "Session", "$filter": { "$created_at": { "$gte": "2026-04-01T00:00:00Z" } }, "$sort": "-$created_at", "$limit": 5, "$fields": [ "$created_at", { "$expandArc": "memories", "$kinds": ["Fact", "Idea"], "$search": "user preferences", "$filter": { "relevance": { "$gte": 0.7 } }, "$sort": "-relevance", "$limit": 10, "$fields": ["content", "relevance"] } ] }

// the wall you hit

Great databases. Still built for tables.

Supabase thinks in columns. Convex in documents. Mongo Atlas in collections. Here's what changes when you think in entities and relationships.

Supabase · Postgres

vs BlitzGraph

The wall

A User who becomes Admin needs a role table.New role? New table, new JOIN, new migration. Every entity change touches the schema.

⚡ BlitzGraph

One entity, multiple kinds.A User can be [User, Admin, Moderator] simultaneously. Kinds compose freely, no migrations.

The wall

"Who wrote this post?" costs a reverse JOIN.Foreign keys go one direction. Reverse lookups need indexes, JOINs, and careful query planning.

⚡ BlitzGraph

Bidirectional arcs, O(1) both ways.Every relationship is stored in both directions. "User → Posts" and "Post → Author", same cost, same index.

Convex · Mongo Atlas

vs BlitzGraph

The wall

No real relationships between documents.References are just string IDs you manage yourself. No traversals, no cardinality, no cascade policies.

⚡ BlitzGraph

Relationships are first-class citizens.Bidirectional arcs with onDelete cascade/restrict/unlink. $expand traverses the graph in the same query.

The wall

Flat documents, no entity evolution.A Task that becomes a Bug needs a type field and conditionals everywhere. Schema changes ripple through app code.

⚡ BlitzGraph

Entities that grow and compose.Add a kind: [Task, Bug]. The entity gains Bug fields and relationships without breaking existing queries.

Table Paradigm · SQL

vs BlitzGraph

The wall

One entity, scattered across tables.A Customer in SQL lives in users, addresses, billing_info, and roles. Four tables, four IDs, four JOINs to reconstruct one entity.

⚡ BlitzGraph

One unit, one ID, forever.A unit has a single ID throughout its entire lifecycle. All its data and relationships are accessible from that one identity.

The wall

Entity evolution means migration hell.A Company that becomes a Prospect, then a Client, then Churned? That's 4 status fields, 4 conditional queries, and a prayer that nothing breaks.

⚡ BlitzGraph

Kinds compose and evolve naturally.Same unit: [Company] → [Company, Prospect] → [Company, Client] → [Company, Churned]. Same ID, new capabilities, zero migrations.

Neo4j · Graph DBs

vs BlitzGraph

The wall

String-based query language.Cypher queries are strings your app generates and your agent guesses at. Parsing errors at runtime, no structured validation.

⚡ BlitzGraph

JSON in, JSON out.BQL is structured JSON. Your agent composes objects, not strings. Schema-validated at compile time with the bql! macro.

The wall

Nodes belong to one label at a time.Neo4j labels are flat tags with no schema, no inheritance, no field isolation. Adding a label doesn't add structured fields.

⚡ BlitzGraph

Units belong to multiple kinds.A unit with kinds [User, Admin, Moderator] inherits each kind's fields, validations, and relationships. Polymorphism is the core model.

// honest comparison

How we stack up

BlitzGraph vs the databases you’re considering. Including where they win. We’d rather be honest.

CapabilityBlitzGraphSupabaseConvexMongoFirebase

Only in BlitzGraph

Multi-kind composition (User + Admin in one entity)✓✕✕✕✕

Bidirectional arcs with O(1) reverse lookup✓✕✕✕✕

Agent sandboxes (isolated subspaces)✓✕✕✕✕

Data model

Graph + document + relational in one engine✓✕✕~✕

Nested graph reads in one query ($expand)✓✕✕✕✕

Referential integrity (onDelete, cardinality)✓✓✕✕✕

Built-in full-text search (BM25)✓~✕~✕

Content type validation (EMAIL, URL, DATE…)✓✕✕✕✕

Files as native values (not a separate service)✓~~~~

Developer experience

Agent-composable queries (no SQL strings)✓~✕~✕

Business logic in the schema (hooks, validations)✓~~~~

Smart transactions (topological, atomic)✓~✓~✕

Where others win today

Realtime / live queries✕✓✓~✓

Years in production✕✓~✓✓

Large community & ecosystem✕✓~✓✓