Show HN: InstantDB – A Modern Firebase

I always assumed that an architectural decision had prevented relational queries in Firebase.

It was jarring to find out that indexes are required for every combination of filters your app applies, but then you quickly realize that Firebase solves a particular problem and you're attempted to shoehorn into a problem-space better solved by something like Supabase.

It's not too dissimilar to DynamoDB vs RDB.

Thanks for creating Firebase!

It's really the definition of an managed database/datastore.

Do you see InstantDB as a drop in replacement ?

To be honest I don't want to have to worry about my backend. I want a place to effectively drop JSON docs and retract them later.

This is more than enough for a hobbyist project, though I imagine at scale things get might not work as well.

This is an aside but “trifecta but with four” actually has an awesome name: “Superfecta”!

You probably heard this a million times but I still remember trying that simple firebase demo of draw in one box; see the results in another and being amazed. That was one of my pushes out of boring enterprise software death by configuration and into software creation based on modern OSS products.

Was pretty neat to see your investment/involvement!

Made me feel quite old that Firebase is no longer "modern" though...

Awesome to see this launch and to see James Tamplin backing this project.

Thank you James!

If we only had doSQL() for everything.

Thank you for the feedback, this makes sense!

I updated the example to include the imports:

```

import { init, tx, id } from "@instantdb/react";

const db = init({ appId: process.env.NEXT_PUBLIC_APP_ID, });

function Chat() {

  // 1. Read
  const { isLoading, error, data } = db.useQuery({
    messages: {},
  });

  // 2. Write
  const addMessage = (message) => {
    db.transact(tx.messages[id()].update(message));
  };

  // 3. Render!
  return <UI data={data} onAdd={addMessage} />;

}

```

What do you think?

Yes. This gives users the vibe of “ this is obvious, if you don’t know it , you are dumb “ .

lol i was wondering the same thing

this is my question too, lol

Co-founder of PowerSync here. Would love to hear what you would like to see improved in PowerSync :) Thanks!

> CouchDB / PocketDB aren’t really up to date anymore.

Source? I’ve been using CouchDB as my game world DB for years, works fine for me?

We hear you on the pain for evolving NoSQL schemas. [1]

For what it's worth, we're built on top of Aurora and support relations so evolution should be much easier!

[1] https://mdp.github.io/2017/10/29/prototyping-in-the-age-of-n...

This is why I’ve always stayed well behind the bleeding edge but still within earshot if anything comes along that sounds like it’s of interest to me. I usually code to work and not for pleasure, although I do a little web programming for friends, but I still use jQuery and Typescript for that, I think the only “new”thing I use is tailwind, which is a bit of a game changer for what I like to do, I never liked CSS but it worked well enough for my needs.

Did they say schemas aren’t supported, or is that implied by the firebase label?

Good point on the update frequency, I believe it is a must to batch the requests and responds for any of this type of lib/service to work in a production environment, a performance report/comparison is still required for ppl to get the idea if this is good to support their business model.

About the synchronized data though I think it's not about the database but the data types designed to sync the data? I worked on multiple-player canvas games and we didn't really care that much about relational db or document db, they worked both fine. I would love to know what's the difference and the challanges.

We do indeed batch frequent updates! Still many opportunities for improvements there, but we have a working demo of a team-oriented tldraw [1]

[1] https://github.com/jsventures/instldraw

We would love to hear more about the architecture you used at Framer. Would you be up for a coffee? My email is stopa@instantdb.com

Would love to hear how you went about doing things at Framer!

Noted about the refresh tokens, thank you!

> One thing I was curious about is how well the system currently supports users with multiple emails? GitHub popularized this pattern, and these days it's pretty much table stakes in the dev tools space to be able to sign in once and use the same account across personal accounts and orgs associated with different emails

Right now there is an assumption of 1 `user` object per email. You could create an entity like `workspace` inside Instant, and tie multiple users together this way for now.

However, making the `user` support multiple identities, and creating recipes for common data models (like workspaces) is on the near-term roadmap.

I really appreciate your message Slava. Your essays were really influential for us.

It's been great iterating with you AJ! Can't wait for what's ahead.

> What's the short summary of how the authorization system works for this?

We built a permission system on top of Google's CEL [1]. Every object returned in a query is filtered by a 'view' rule. Similarly, every modification of an object goes through a 'create/update/delete' rule.

The docs: https://www.instantdb.com/docs/permissions

The experience is similar to Firebase in three ways:

1. Both languages are based on CEL 2. There's a distinct separation between data retrieval and access policy 3. You can start on a happy path when developing, and lock down later.

AFAIK, Firebase Realtime can be more efficient, as it can tell if a permission check has passed statically. I am not sure if Firestore works this way. We wanted to be more dynamic, to support more nuanced rules down the road (stuff like 'check this http endpoint if an object has permissions'). We took inspiration Facebook's 'EntPrivacy' rules in this respect.

It’s not quite the same thing but nearby:

I built a EAV secondary index system on top of Postgres to accelerate Notion’s user-defined-schema “Databases” feature about a year ago. By secondary index, I mean the EAV table was used for queries that returned IDs, and we hydrated the full objects from another store.

We’d heard that “EAV in Postgres is bad” but wanted to find out for ourselves. Our strategy was to push the whole query down to Postgres and avoid doing query planning in our application code.

When we first turned it on in our dogfood environment, the results looked quite promising; large improvement compared to the baseline system at p75, but above that things looked rough, and at p95 queries would never complete (time out after 60s).

It worked great if you want to filter and sort on the same single attribute. The problem queries were when we tried to query and sort on multiple different attributes. We spent a few weeks fixing the most obviously broken classes of query and learned a lot about common table expressions, all the different join types, and strategies for hinting the Postgres query planner. Performance up to p95 was looking good, but after p95 we still had a lot of timeout queries.

It turns out using an EAV table means Postgres statistics system is totally oblivious to the shape of objects, so the query planner will be very silly sometimes when you JOIN. Things like forget about the Value index and just use a primary key scan for some arms of the join because the index doesn’t look effective enough.

It was clear we’d need to move a lot of query planning to the application, maintain our own “table” statistics, and do app joins instead of Postgres joins if Postgres was going to mess it up. That last part was the last nail in the coffin - we really couldn’t lean on join in PG at all because we had no way to know when the query planner was going to be silly.

It was worth doing for the learning! I merged a PR deleting the EAV code about a month ago, and we rolled out a totally different design to production last week :)

I've also found triple stores to have terrible performance, but it looks like the intended use-case for this (like Firebase) is rapid development, prototyping, and startups. You aren't going to generate enough traffic when you're building an MVP for this to be an issue.

And it's a hosted service, so the performance issues are for the InstantDB team to worry about, and they can fold it into the price they charge. It does mean that your application architecture will get locked in to something that costs a fortune in server bills when it gets big, but from InstantDB's POV, that's a feature not a bug. From your POV as a startup it may be a feature as well, since if you get to that point you'll like have VC to blow on server bills or use to rewrite your backend.

So far we haven't hit intractable problems with query performance. One approach that we could evolving too down the road is similar to Tao [1]. In Tao, there are two tables: objects and references. This has scaled well for Facebook.

We're also working on an individual Postgres adapter. This would replace the underlying triple store with a fully relational Postgres database.

[1] https://www.usenix.org/system/files/conference/atc13/atc13-b...

Absolutely. Instant has similar design goals to Rails and ActiveRecord

Here are some parallels your example:

A. ActiveRecord:

```

post = Post.find_by(author: "John Smith") post.author.email = "john@example.com" post.save

```

B. Instant:

```

db.transact( tx.users[lookup('author', 'John Smith')].update({ email: 'john@example.com' }), );

```

> In React/Vue/Solid, I want to say express things like this:

Here's what the React/Vue code would look like:

```

function BlogPostDetailComponent(props) {

  // `useQuery` is equivelant to the `subscribe` that you mentioned:

  const { isLoading, data, error } = db.useQuery({posts: {author: {}, $: {where: { id: props.id }, } })
  
  if (isLoading) return ...
  
  if (error) return .. 
  
  function updateAuthorName(newName) {
  
    // `db.transact` does what you mentioned: 
    // it attempts to persist any pending changes to browser storage, then
    // sync to remote db, rolling back changes if there's a failure, and
    // gives an easy way to show an error toast if the update failed. (it's awaitable)
  
    db.transact(
      tx.authors[author.id].update({name: newName})
    )
  
  }

  return (
    <>
      ...
    </>
  )

}

```

From what you say, seems like Meteor + React would deliver almost the exact syntax you want, although it's MongoDB instead of SQL.

Reference: https://react-tutorial.meteor.com/simple-todos/02-collection...

Every day, we get closer to what Ember.js did/does.

> Is the datalog engine exposed? Is there any way to cache parsed queries?

We don't currently expose the datalog engine. You _technically_ could use it, but that part of the query system changes much more quickly.

Queries results are also cached by default on the client.

> Other datalog engines support recursive queries, which makes my life so much easier. Can I do that now with this?

There's no shorthand for recursive queries yet, but it's on the roadmap. Today if you had a data model like 'blocks have child blocks', you wanted to get 3 levels deep, you could write:

```

useQuery({ blocks: { child: { child: {} } } });

```

> Also, why the same name as the (Lutris) Enhydra java database?

When we first thought of the idea for this project, our 'codename' was Instant. We didn't actually think we could get `instantdb.com` as a real domain name. But, after some sleuthing, we found that the email server for instantdb.com went to a gentleman in New Zealand. Seems like he nabbed it after Lutris shut down. We were about to buy the domain after.

> Given that it's implemented clojure and some other datalog engines are in clojure, can you say anything about antecedents?

Certainly. Datomic has had a huge influence on us. I first used it at a startup in 2014 (wit.ai) and enjoyed it.

Datalog and triples were critical for shipping Instant. The datalog syntax was simple enough that we could write a small query engine for the client. Triples were flexible enough to let us support relations. We wrote a bit about how helpful this was in this essay: https://www.instantdb.com/essays/next_firebase#another-appro...

We studied just about all the codebases you mentioned as we built Instant. Fun fact, datascript actually supports our in-memory cache on the server:

https://github.com/instantdb/instant/blob/main/server/src/in...

This is from me. I didn't realize the connection to Lutris + Enhydra. It should be listed as a "Acquired Company" + "Abandoned Project". Wikipedia also says that it lasted until 2001. Usage is different from development/maintenance. I will update the entry for the old InstantDB and add an entry for this new InstantDB.

I think given that the original InstantDB died over two decades okay and is not widely known/remembered, reusing the name is fine.

> Would you be interested in elaborating more about this decision/design?

Our initial intuition was to expose a language like SQL in the frontend.

We decided against this approach for 3 reasons:

1. Adding SQL would mean we would have to bundle SQLite, which would add a few hundred kilobytes to a bundle

2. SQL itself has a large spec, and would be difficult to make reactive

3. What's worst: most of the time on the frontend you want to make tree-like queries (users -> posts -> comments). Writing queries that like that is relatively difficult in SQL [1]

We wanted a language that felt intuitive on the frontend. We ended up gravitating towards something like GraphQL. But then, why not use GraphQL itself? Mainly because it's a separate syntax from javascript.

We wanted to use data structures instead of strings when writing apps. Datastructures let you manipulate and build new queries.

For example, if you are making a table with filters, you could manipulate the query to include the filters. [2]

So we thought: what if you could express GraphQL as javascript objects?

``` { users: { posts: { comments: { } } } ```

This made frontend queries intuitive, and you can 'generate' these objects programatically.

For more info about this, we wrote an essay about the initial design journey here: https://www.instantdb.com/essays/next_firebase

[1] We wrote the language choice here: https://www.instantdb.com/essays/next_firebase#language

[2] We programatically generate queries for the Instant Explorer itself: https://github.com/instantdb/instant/blob/main/client/www/li...

Thank you. We admire ActiveRecord's DSL. I especially like their `validation` helpers, simple error reporting, and the `before` / `after` create hooks.

Thank you for the kind words!

> When a schema is provided, is it fully enforced?

Right now the schema understands the difference between attributes and references. If you specify uniqueness constraints, they are also enforced. We haven’t supported string / number yet, but are actively working towards it. Once that’s supported, we can unlock sort by queries as well!

> Migrations though... hope you focus on it early if you haven't yet!

We don’t have first class support for migrations yet, but are definitely thinking about it. Currently folks use the admin SDK to write migration scripts.

Question: do you have any favorite systems for migrations?

Thank you the kind words.

> 1. the usual "vendor locked in". Is there a recommended escape hatch?

Instant is completely open source. We have no private repos, so in the event that you want to run the system yourself, you can fork it.

> 2. any big clients on this yet or at what scale do you expect people to start rolling their in house product

We have startups in production using us today. We would love to learn more about your use case. You can reach out to us directly at founders@instantdb.com

Thank you. Meteor was definitely an inspiration.

> I'm missing clarity about how do I escape Instant DB when I need to, and how to make it part of a larger system.

Instant is completely open source. We have no private repos, so in the event that you want to run the system yourself, you can fork it.

> how to make it part of a larger system.

If you have an existing app, right now I would suggest storing the parts that you want to reactive on Instant.

We're working on a Postgres adapter. This would let you connect an existing database, and use Instant for the real-time sync. If you'd be interested in using this, reach out to us at founders@instantdb.com!

Glad to hear the experience so far has been good!

> larger aggregates and more complex queries

Currently Instant supports nested queries, pagination, IN, AND, and OR. We have an internal implementation for COUNT [1], but need to update permissions for aggregates.

We're always hacking away on blocker features. If we can't get to it in time and it blocks your app, you can reach to the admin SDK for an escape hatch [2]

[1] The 'admin-only' count starts here: https://github.com/jsventures/instant/blob/main/server/src/i...

[2] https://www.instantdb.com/docs/backend

I'm curious what a bouldering app is? As in climbing, like a route checklist type thing?

> creating a user table and ensuring that emails are unique - I've done it 50 times with Postgres. Is that part built out yet?

Yes. Auth comes out of the box with Instant. You get support magic code-based auth, Google OAuth, and have an option to extend it using your own backend if you prefer.

P.S Aqua seems very cool; I broke my thumb 6 months ago, and would have definitely appreciated a tool like that.

We're currently working on a Postgres adapter. If you have an existing app and would be interested in using Instant with it, please send us a note: founders@instantdb.com

The way the Postgres adapter would work: You give us your database url [1], and Instant handles the real-time sync. [2]

For roll-out, we'll test it ourselves first and then take on beta users.

[1] Encrypted at rest: https://github.com/instantdb/instant/blob/main/server/src/in...

[2] Here's a fun 'pg introspection' function: https://github.com/instantdb/instant/blob/main/server/src/in... . You can take sneak peak through codebase by searching 'byop'.

Not related to Instant, but saw that the backend is available on their Github: https://github.com/instantdb/instant/tree/main/server

The backend is completely open source. The code is in the `server` directory:

https://github.com/instantdb/instant/tree/main/server

Zero is by the Replicache team and they are really nice guys. I've interacted with Aaron Boodman quite a bit in their Discord and he was very responsive and helpful, and took a lot of my comments into consideration in improving the product. It's a very hot space which IMO will revolutionize how we build GUIs IMO. Replicache is a bit hard to grasp at first but the nice thing is you bring your own DB (vs. use a service). I think this project needs more recognition. I would hate to see them fade just because they don't have the fancy backers like YC and the usual crowd. If they keep at it they might prevail since VC-backed startups like InstantDB tend to sell out and flame out.

I think it would be difficult to compare at this point, as there aren't many details about Zero outside of the blog on their landing page. I believe it's very much in early (but active) development.

From that blog: > We are working toward a source release in summer 2024 and an open beta EOY 2024.

Did Google kill it?

Imagine a you want to create a 'todo' list.

If you used classic Rails, you'd be very productive. You could write most of your code on the server, and sprinkle some erb templates.

However, if you want to improve the UX, you generally end up writing more Javascript. Once you do that, things get hairier:

You create REST endpoints, funnel data into stores, normalize them, and denormalize them. Then you write optimistic updates. If you want offline mode, you worry about IndexedDB, and if you want it to multiplayer, you end up with stateful servers.

If you had a database on the client, you wouldn't need to think about stores, selectors, endpoints, or local caches: just write queries. If these queries were multiplayer by default, you wouldn't have to worry about stateful servers. And if your database supported rollback, you'd get optimistic updates for free.

This is the inspiration for Instant: it gives you a 'database' you can use in the browser.

If you're curious, I wrote a more detailed essay about this here:

https://www.instantdb.com/essays/db_browser#client

We don't have support a sync api with an external store. Two curious questions: what db do you use, and what would your ideal API look like?

We don't currently expose the `domain` a request comes from in permissions, but we'd be happy to add that in. I've opened up a ticket here [1].

[1] https://github.com/instantdb/instant/issues/18

having abused a number of firebase databases I can say that the domain restrictions that firebase has don't do anything at all.

When Firebase was first built, using a document store was a great choice for building a local abstraction that enabled optimistic updates and offline mode. But the lack of relations makes it a real schlep to change your data model when you start adding new features to your app. You end up hand-rolling joins or duplicating your data to avoid complete re-writes. [1]

With Instant, you get a relational Firebase.

[1] https://www.instantdb.com/essays/next_firebase#firebase

> but it did surprise that someone would decide to use this syntax over a syntax used in other Datalog engines (and predating Datomic itself).

We are clojure programmers, so our introduction to Datalog was actually though Datomic in 2014. We are fans of other query syntaxes (SparQL looks cool too), but we find Datomic's flavor the most ergonomic for us, and it's an added win for us that we can express queries as plain data structures

Thank you! I just updated the tutorial:

1) Added in the 'how'

2) Changed the sentence on mobile to say: 'Check out the walkthrough below, and the full code example right after.'

I have done a little more reading and it appears that one fundamental difference between InstantDB and ElectricSQL is that InstantDB does not sync with standard PostgreSQL tables. ElectricSQL does.

If that understanding is correct, then InstantDB may be a good fit if you are starting your database from scratch or can completely get rid of your existing one.

I have more than 170GBs of data in a SQL database. I can sync parts of it to ElectricSQL using shaped queries.

Yes that is a deal breaker if not possible

Thank you for the kind words.

> How well do you think this can scale.

We have startups in production using Instant. It could hiccup if you get a big spike of traffic, but all of us will be on deck to fix it.

> Any plans to make native SDKs for iOS and Android?

It's definitely on the roadmap, but we want to get the Javascript / React Native experience really right first.

> Clojure + TS seems to be a good way to go

TS as in TypeScript? They're on two very opposite ends of a spectrum, what would you use it for if you're already using Clojure? And what's the "hang up" with CLJS?

I'm dreaming about a Next-like framework that will do React SSR in GraalVM JS engine but will do data fetching, routing and other stuff in Clojure.

Clojure was made with databases and concurrency in mind. We've used it at previous startups, projects, and find it a productive language.

Also the clojure community is amazing. The clojurians slack is one of the most helpful communities for solving hard problems. Stopa will be giving a talk at at the conj later this year [1]

[1] https://2024.clojure-conj.org/#/speakers

If the field is indexed, we limit the size to 1 kilobyte. If it isn't indexed, the maximum size is 250 mb

Firebase, Parse, and Meteor were definitely inspirations for us.

Instant's main advantage is that we support relations. This means you can create data models like 'users -> comments -> apps'. For a bit more about why this matters, this is a good post:

https://mdp.github.io/2017/10/29/prototyping-in-the-age-of-n...

You can already self-host! We have instructions on standing up the server on our github [1]

[1] https://github.com/instantdb/instant/tree/main/server

Thank you, I went ahead and fixed them [1]

[1] https://github.com/instantdb/instant/pull/29

I saw in the docs that it uses IndexDB. Didn’t read carefully to understand how full is the replica and if it’s possible to make 100% offline app and what would be the limits of storage in the browser.

Also it would be nice to clarify memory consumption.

In general I’m glad such thing now exists!

Yes, queries are cached locally on IndexedDB

I didn’t clock the use of “triples” as the store on first read. That’s a non-starter for existing dbs and pretty much a dead end for anyone who eventually wants a db structure they can use outside of this model.

Ah, sorry.

I thought this was a firebase alternative in the sense that it's an open source library that works with Postgres, but it's a cloud storage service with a nifty frontend.

We provide support for optimistic updates and offline mode out of the box. Our idea is to give you the best of both worlds in terms of Firebase and Supabase. [1]

[1] https://www.instantdb.com/essays/next_firebase#the-missing-c...

I mean, Meteor did a lot of these things, and they worked fine for toy examples. But if you started to do something of any scale meteor choked.

To be fair, maybe it was unrealistic to expect Meteor to do real-time communication for my game.

Thanks for the request! Made an issue to track this here! [1]

[1] https://github.com/instantdb/instant/issues/19

We open sourced all parts of Instant with this repo. There are no other private repos. The backend is written as a multi-tenant system, but you could run it with a single 'app'. If you try to set it up and have any issues, please let us know.

Thank you! Awesome work with pglite as well, very exciting tech!

We use the concept of 'topics'. A topic encodes: 'The part of the index a query cares about'.

For example, given a query like "fetch user where id = 1", there could be a topic like "users:id:1" [1]

When a WAL record comes in, we find queries by their topics, and invalidate them. This triggers a refresh.

This is inspired by Figma's LiveGraph [2], which in turn is inspired by Asana's Luna [3]. The essays cover the idea in more detail, but you can also start diving into the code, at invalidator.clj [4]

[1] This is an example. Inside Instant, we encode them as a 'datalog' pattern. Something like `[:ea "1" :users/id]` [2] https://blog.asana.com/2020/09/worldstore-distributed-cachin... [3] https://www.figma.com/blog/livegraph-real-time-data-fetching... [4] https://github.com/instantdb/instant/blob/main/server/src/in...

I thought the same when reading the headline, but the approaches are quite different.

Pocketbase (at a very high level) takes sqlite and layers on a go ORM and a relatively loose (on the scale from typical rest/http on one end to graphql on the other) autogenerated REST api, a grammar for expressing authz constraints, websocket updates and an embedded js engine for registering handlers for the various crud model and webserver events.

It's _very_ well designed, but I think the approach taken here with datalog and triples on top of postgres is worth a close look as the trade-offs will be very different, though it does seem like a lot of layers

Even though the two may not be fully comparable, I would like to give another vote to pocketbase, simply because I've found the experience of working with it to be absolutely stellar.

[dead]

We provide support for optimistic updates and offline mode out of the box. Without these it's a real schlep to build Linear-level applications. [1]

[1] https://www.instantdb.com/essays/next_firebase#supabase-hasu...

Why would I use this over Yjs or Automerge?

Yjs is great if you sharing a single data structure, like a document. It doesn't work as well if you are sharing relational data, like 'documents for a workspace'.

We are thinking about supporting Yjs for document editing inside Instant

Thank you!

And yes you can self host today. We have instructions on standing up a server on our github [1]

[1] https://github.com/instantdb/instant/tree/main/server

> Looks great! How is the migration story when schema changes are needed?

We have an admin API you can use to write migration scripts. The process is a bit manual though, and a more integrated solution is on the roadmap

> How do you deal with old clients?

Instant treats the the backend the source of truth. If there's an inconsistent cache, we drop the cache and fill it from scratch. We tend to write code that's backwards compatible, and suggest the GraphQL ethos: make sure when changing schema that active clients won't break

Asking the real questions.

Also, how does backward compatibility work? An offline first app might use a stale version of the code sometimes right?

We built a permission system on top of Google's CEL [1]. Every object returned in a query is filtered by a 'view' rule. Similarly, every modification of an object goes through a 'create/update/delete' rule.

You can learn more about the rules language in the permission docs: https://www.instantdb.com/docs/permissions

[1] https://github.com/google/cel-java

We offer a generous free tier which doesn't limit your number of projects, never pauses, and available for commercial use. The pro plan is $30/mo and then pay for usage.

We use PG replication slots and listen to updates. This doesn't add much load to the database -- it's similar to having a read replica. Adding more servers would mean more replication slots, and could slow down PG. When this happens, we'll likely replicate PG's WAL onto Something like Kafa. This is what LiveGraph does [1]

[1] https://www.figma.com/blog/livegraph-real-time-data-fetching...

`db.transact` returns a promise. It 'resolves' when the transaction is guaranteed by the server, or if you are offline, if it's been enqueued. I'll note to include some information about this in the docs, thank you.

We love the small API and fast getting started experience of Firebase. We take a lot of inspiration from them for our write api. Hand-rolling joins was often a pain point though and we thought a graphql-like interface was a better experience.

Thank you!

We wanted to lean towards a faster getting started experience. We are thinking about options to change the default, or introducing a kind of 'wildcard' in permissions.

Both convex and Instant let you build apps quickly without worrying about the backend. Where Instant differs, is that queries and transactions can run on the client: you get optimistic updates and offline mode by default. On the other hand, convex lets you define queries as functions that can run on the edge. I haven't used convex deeply, but this is my understanding.

We have an unofficial HTTP api, will add it to the docs but we've already had folks use it for non-js backends! [1]

[1] https://paper.dropbox.com/doc/Unofficial-Admin-HTTP-API--CVa...

The core client SDK is pretty small -- it's about 10K LOC. We want to get the core abstractions right in JS-based environments, than expand. We really like Mitchel Hashimoto's post about how he built Ghostty on different platforms [1]

[1] https://mitchellh.com/writing/zig-and-swiftui

Yes, our bet with Instant is that browsers have become so powerful, that we can run many computations locally, and don't need to wait for the server all the time.

This gave me a good chuckle :)

We have basic example demonstrating how you can use Instant to make games [1] and a live iOS app built with Instant and React Native [2]

[1] https://www.instantdb.com/examples?#8-merge-tile-game

[2] https://github.com/jsventures/stroopwafel

RethinkDB is an certainly inspiration for us! We thought their and design was very elegant.

We wanted to bring the best of both worlds by packaging optimistic updates and offline mode with the power of relations [1]

[1] https://www.instantdb.com/essays/next_firebase#the-missing-c...

The third paragraph in the link says the following

> Currently we have SDKs for Javascript, React, and React Native.

We designed Instant so that the client store works as a cache: it only stores a partial amount of data: just the queries you need to load the page. The server is responsible for storing all the data.

Both Instant and Liveblocks support ephemeral data: like cursors, activity indicators, and presence.

The difference comes to storing data: Liveblocks persists data based on 'room'. Instant supports full relations, so you can create a query like: "listen for items in these 3 rooms"

This is on our radar and made an issue for tracking and visibility [1]

[1] https://github.com/instantdb/instant/issues/19

Yes, the server is open sourced here: https://github.com/instantdb/instant/tree/main/server