In two sentences: Instant is a modern Firebase. We make you productive by giving your frontend a real-time database.

What does that actually mean?

Imagine you’re a hacker who loves building apps. You have an exciting idea, and are ready to make something people want. You want to build an MVP fast, that doesn’t completely suck. So how do you do it?

Most of the time we make a three-tier architecture with client, server, and a database. On the server side we write endpoints to glue our frontend with our database. We might use an ORM to make it easier to work with our db, and add a cache to serve requests faster. On the client we need to reify json from the server and paint a screen. We add stores to manage state, and write mutations to handle updates. This is just for basic functionality.

If we want our UIs to feel fast, we write optimistic updates so we don’t need to wait for the server. If we want live updates without refreshing we either poll or add websockets. And if we want to support offline mode, we need to integrate IndexedDB and pending transaction queues.

That’s a lot of work!

To make things worse, whenever we add a new feature, we go through the same song and dance over and over again: add models to our DB, write endpoints on our server, create stores in our frontend, write mutations, optimistic updates, etc.

Could it be better? We think so! Instant compresses the schleps:

If you had a database on the client, you wouldn’t need to manage stores, selectors, endpoints, caches, etc. You could just write queries to fetch the data you want. If these queries were reactive, you wouldn’t have to write extra logic to re-fetch whenever new data appears. Similarly you could just make transactions to apply mutations. These transactions could apply changes optimistically and be persisted locally. Putting this all together, you can build delightful applications without the normal schleps.

So we built Instant. Instant gives you a database you can use in the client, so you can focus on what’s important: building a great UX for your users, and doing it quickly.

Instant is a real-time database you can use on the frontend. We give you the best of both Firebase and Supabase, a sync-engine with support for relations. This is the kind of tech that companies like Figma, Notion, and Linear build internally to power their products (Try out the demo)

We’re looking for a founding full-stack engineer to join our team in San Francisco. We’re looking for someone who:

1. Wants to build front-end tech (read: a sync engine!) to enable devs to build delightful applications
2. Enjoys crafting UIs that people use for hours
3. Has an interest in learning or working in Clojure (we’re happy to induct you into the cult!)

Our current stack looks like so:

• We offer client SDKs, a CLI tool, and web GUI to interact w/ Instant. All written in Typescript
• We have a server written in Clojure for managing websocket connections, parsing queries, running permissions, and broadcasting novelty.
• All of which sits on top AWS Aurora Postgres

Inside the SDK there's a client-side database which can run queries just the like the server does. The client-side DB is what makes it possible for Instant to work offline, and to get optimistic updates out of the box. And it's full of problems that make computer science textbooks come alive. Here are some opportunities for improvements we’d love your help on.

Better joins: the client runs a nested loop to implement joins. But as we increase how much we cache, nested loops could become a problem. Perhaps it's time to add hash joins!

Better indexes: we use a map of maps for our indexes. This works, but comparison queries will be less efficient then they have to be. Perhaps it's time to consider writing an OrderedSet

Better introspection: we built a state machine to manage how different events interact: websocket updates, connection changes, client / server changes. But it's quite hairy and hard to reason about. Can we make it easier to observe events and replay them? Perhaps we could look into the actor model or structured concurrency for inspiration.

Better local storage: we treat IndexedDB as a key values store and serialize large chunks of state. Can we serialize in smaller chunks instead?

Less re-renders: Right now queries can change more than is needed. We want every update to be finer-grained, so users have less re-renders.

There’s also new surfaces to be built. Right now we have a GUI sandbox that lets you run queries and transactions. This can be very useful for debugging but there’s a lot missing here. One of the biggest pain points users have is crafting and testing permissions. It would be great if we had a better experience for rapidly testing permission rules against data.

Sound interesting? If so here’s a few more details :)

• Location: We're based in San Francisco, CA!
• In-person or open to relocation only: We're a small team and we really do prefer all working together in person!
• Compensation: Sliding scale between 0.5%-2% equity and 150k - 200k base + medical/dental/vision benefits

Our vision is to be the infrastructure for all apps of the future. If this jives with you we should really talk 🙂.

Our architecture is inspired by Figma’s LiveGraph and Asana’s LunaDB. We also built Instant to be multi-tenant and don’t need to spin up an actual database for users. This enables us to give users a database in <10ms with a click of a button. And unlike our competitors, we can offer a free tier to users where their projects are never paused and there is no limit to the number of active projects they can have.

To learn more about how Instant works under the hood, check out our essay A Graph-Based Firebase:

https://www.instantdb.com/essays/next_firebase