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. It starts with how we store data.
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. This is the key insight that unlocks everything else.
| entity | attribute | value |
|---|---|---|
| user_1 | "name" | "Alice" |
| goal_1 | "title" | "Ship v2" |
| goal_1 | "status" | "active" |
| goal_1 | "owner" | user_1 |
InstaQL: reading data
To query this data, developers write InstaQL, a declarative syntax using plain JavaScript objects and arrays. 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.
SQL on the server
On the server, the same InstaQL queries take a different path. They're translated into SQL and executed against Postgres Aurora. 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. Write operations optimistically modify the client-side triple store for instant feedback, then send transactions to the server as the source of truth. If the server rejects a write, the local store rolls back automatically.
Permissions: access control
Every read and every write passes through a permission layer based on Google's Common Expression Language (CEL). Permissions are expressive enough to handle complex rules like role-based access, row-level filtering, and field-level visibility, but readable enough that you can reason about them at a glance.
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.