Building the database for the AI era
We started Instant because we believed we needed a new kind of database for the future of app development. Now, with agents building more software than ever, that need is bigger than ever.
Our story
In 2021, we wrote “Database in the Browser”, a deep exploration of every pain point developers face building modern apps. Fetching data, keeping it consistent, optimistic updates, offline mode, permissions. The thesis was simple: these are all database problems in disguise.
A year later, we published “A Graph-Based Firebase”, which laid out how a triple store and a new query language could give developers the relational power of Supabase with the real-time magic of Firebase. The essay went viral and the team raised a seed round to build Instant.
Two years of heads-down development later, Instant was open-sourced. It hit the front page of Hacker News with 1,000+ upvotes. The demo of spinning up a database instantly resonated with the community.
In 2025 Instant became a full backend solution with database, auth, permissions, and storage all governed by the same data model. Then came create-instant-app and end-to-end typesafety, so getting started was as easy as a single terminal command.
In 2026 Instant entered the AI era. Modern LLMs natively know how to use it. Give them a bit of context and they can build apps like Counter-Strike and Instagram in a few prompts.
With the rise of agents, we believe more software will be built than ever. Infrastructure needs to scale to millions of apps, not just millions of users. Instant is the database for that future.
The Essay
"Database in the Browser" outlines what the future of app development could look like. The ideas resonate with thousands of developers.
The Architecture
"A Graph-Based Firebase" goes viral on Twitter. The team lays out how a triple store and a new query language could give developers the best of Firebase and Supabase.
Open Source Launch
After two years of development, Instant is open-sourced. Hits the front page of Hacker News with 1,000+ upvotes. The demo of spinning up a database instantly captures developer imagination.
Full Backend
Instant becomes a complete backend as a service with database, auth, permissions, and storage.
Create Instant App
Launch of create-instant-app and end-to-end typesafety. Getting started with Instant becomes as easy as a single terminal command.
Instant sings with AI
Modern LLMs natively know how to use Instant. Agents can build full apps in a few prompts. Instant handles 10,000+ concurrent connections and 1,000+ queries per second in production.
What we believe
Sync is the future
Every app will eventually need real-time sync, optimistic updates, and offline mode. These shouldn't require a team of engineers. They should come for free.
Good abstractions compound
When the right abstraction exists, it's a waste of tokens to build it again. One coherent package beats ten separate services wired together.
Agents need infrastructure too
In the AI era, more apps will be built than ever. We need hosting that scales to millions of apps, not just millions of users.
Developer experience is everything
A 12-line chat app. A single terminal command to get started. Schema, permissions, and queries all in your code. If it's not delightful, we haven't shipped.
Under the hood
Instant looks simple on the surface. A few lines of code and your app has a real-time backend. But there's a lot of interesting architecture that makes this possible.
Triples: the foundation
All data in Instant is stored as triples: [entity, attribute, value]. A user's name, a goal's title, a relation between them. They're all expressed the same way.
This simple, uniform structure can model any entity and any relationship. Because triples work the same on both the frontend and backend, we can use the same data model everywhere.
1// Fetch all goals with their todos2db.useQuery({3 goals: {4 todos: {},5 },6});1{2 "goals": [3 {4 "id": healthId,5 "title": "Get fit!",6 "todos": [...]7 },8 {9 "id": workId,10 "title": "Get promoted!",11 "todos": [...]12 }13 ]14}1SELECT g.*,2 COALESCE(3 (SELECT json_agg(t.*) FROM todos t WHERE t.goal_id = g.id),4 '[]'5 ) AS todos6FROM goals g;InstaQL: Reading data
Developers write InstaQL, a declarative syntax using plain JavaScript objects. You describe the shape of the data you want, and that's the shape you get back.
No joins, no SQL, no GraphQL resolvers. The query language was designed so that the shape of the query mirrors the shape of the result.
Datalog on the frontend
On the client, InstaQL queries compile to Datalog, a logic-based query language that runs in a lightweight engine right in the browser.
This local datalog engine is what makes optimistic updates possible. When you mutate data, the change applies to the local triple store instantly. The engine re-evaluates affected queries and your UI updates before the server even responds.
{ todos: { $: { where: { done: } } } }
PostgresWITH done_triples AS ( SELECT entity_id FROM triples WHERE app_id = 'instalinear' AND ave AND attr_id = 'todo-done' AND value = ), todo_data AS ( SELECT t.entity_id, t.attr_id, t.value FROM triples t JOIN done_triples d ON t.entity_id = d.entity_id WHERE t.app_id = 'instalinear' ) SELECT * FROM todo_data
SQL on the server
On the server, the same InstaQL queries take a different path. They're translated into SQL and executed against Postgres.
You get the performance and reliability of a battle-tested database. One query language, two execution paths: datalog locally for speed, SQL on the server for truth.
InstaML: Writing data
For writes, developers use InstaML, a simple API for creating, updating, deleting, and linking data. On the client, each operation is transformed into normalized triple steps. On the server, those steps become SQL executed against Postgres.
db.transact( db.tx.todos[id()].update({ title: "Ship the feature", done: false }))
INSERT INTO triples (entity_id, attr_id, value) VALUES ('id-1', 'todos/title', 'Ship the feature'), ('id-1', 'todos/done', false), ('id-1', 'todos/id', 'id-1')
{ todos: {} }Invalidations and the WAL
When the server acks a write, we need to make sure all subscribed queries get refreshed. We tail Postgres's Write-Ahead Log (WAL) to see which triples changed.
We also record all active queries as patterns of triples. This lets us determine exactly which queries are affected by a change, and send invalidation messages via websockets to just those clients.
Permissions layer
Every read and every write passes through a permission layer based on Google's Common Expression Language (CEL).
Permissions control who can see and change data at a granular level.
const rules = { orders: { allow: { view: "isOwner || isAdmin", }, bind: { isOwner: "auth.id == data.customerId", isAdmin: "'admin' in auth.ref('$user.roles.type')" } } };
| id | customer | item | total | rule |
|---|---|---|---|---|
| 101 | Alice | Headphones | $79 | isOwner → false, isAdmin → falseisOwner → true, isAdmin → false |
| 102 | Bob | Keyboard | $129 | isOwner → false, isAdmin → falseisOwner → false, isAdmin → false |
| 103 | Alice | Monitor | $349 | isOwner → false, isAdmin → falseisOwner → true, isAdmin → false |
| 104 | Charlie | Mouse | $49 | isOwner → false, isAdmin → falseisOwner → false, isAdmin → false |
Offline by default
Instant persists your query results on device automatically. When the network drops, queries keep resolving from the cache. Mutations are saved to a persistent outbox before they're ever sent to the server.
When the connection returns, the outbox flushes in order and the server reconciles. You don't enable offline mode. It's already on.
Multi-tenant Core
We designed Instant from the ground up to be multi-tenant. Queries and writes include an appId that scopes operations to a specific app.
The server enforces this scoping, so data is securely partitioned between apps without needing to spin up separate hardware.
This is what allows us to offer a free tier with unlimited apps and no pausing.
Come build with us
We're always looking for exceptional hackers who want to work on hard problems at the intersection of databases, sync, and AI.