The AI-native backend.
Idea in, API out.
Model reality as it is, in graphs. Your agents compose typed JSON queries programmatically. No SQL, no joins, no ORMs.
Explore the database live.
No setup. No account needed.
Open the playground, write a query, and see results instantly.
Queries, hooks, validations, computed fields. All included. Build your own backend for free →
Model reality,
not tables.
Entities with multiple kinds. Relationships that traverse both ways. A typed JSON query language your agent composes correctly.
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.
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.
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, and exact 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.
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.
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.
GraphQL-like reads, as typed JSON.Fetch a root entity, expand relationships, project nested fields — in one request. Same filter, sort, and limit shape at every depth. Like GraphQL, but without the schema ceremony.
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.
Filter through relationships.Query by connected data, not just local fields. Traverse sessions, memories, owners — without stitching joins in application code.
// 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" } } ] } ] }
// Recent sessions with arc metadata on high-relevance memories. { "$kinds": "Session", "$filter": { "$created_at": { "$gte": "<datetime>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"] } ] }
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.
vs BlitzGraph
A User who becomes Admin needs a role table.New role? New table, new JOIN, new migration. Every entity change touches the schema.
One entity, multiple kinds.A User can be [User, Admin, Moderator] simultaneously. Kinds compose freely, no migrations.
"Who wrote this post?" costs a reverse JOIN.Foreign keys go one direction. Reverse lookups need indexes, JOINs, and careful query planning.
Bidirectional arcs, O(1) both ways.Every relationship is stored in both directions. "User → Posts" and "Post → Author", same cost, same index.
vs BlitzGraph
No real relationships between documents.References are just string IDs you manage yourself. No traversals, no cardinality, no cascade policies.
Relationships are first-class citizens.Bidirectional arcs with onDelete cascade/restrict/unlink. $expand traverses the graph in the same query.
Flat documents, no entity evolution.A Task that becomes a Bug needs a type field and conditionals everywhere. Schema changes ripple through app code.
Entities that grow and compose.Add a kind: [Task, Bug]. The entity gains Bug fields and relationships without breaking existing queries.
vs BlitzGraph
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.
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.
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.
Kinds compose and evolve naturally.Same unit: [Company] → [Company, Prospect] → [Company, Client] → [Company, Churned]. Same ID, new capabilities, zero migrations.
vs BlitzGraph
String-based query language.Cypher queries are strings your app generates and your agent guesses at. Parsing errors at runtime, no structured validation.
JSON in, JSON out.BQL is structured JSON. Your agent composes objects, not strings. Schema-validated at compile time with the bql! macro.
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.
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.
How we stack up
BlitzGraph vs the databases you’re considering. Including where they win. We’d rather be honest.
| Capability | BlitzGraph | Supabase | Convex | Mongo Atlas | Firebase |
|---|---|---|---|---|---|
| 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 | ✕ | ✓ | ✓ | ~ | ✓ |
| Battle-tested at scale | ✕ | ✓ | ~ | ✓ | ✓ |
| Mature client ecosystem & community | ✕ | ✓ | ~ | ✓ | ✓ |