I'd suggest including a skill for this, or if there's already one linking to it on the blog!

InstantDB is a joy to work with. Granted, I've only ever built small toy projects with it, but it's my go-to. Just so much simpler than anything else I've tried in this space.

The core product is so good that the AI emphasis feels weird. Hopefully that's just marketing and not a pivot. Unfortunate if that's what it takes to get funding these days.

Don't get me wrong, as I look for some simple backend for an app I plan it does look another awesome alternative.

But what I'm not understanding is, what makes it 'ai-coded' focused?

And least, vs. other backends, it seems to be TS focused. do you have plans to have some drop-in bindings for (native) mobile platforms?

It’s fun to see highly reactive apps converging on Triples, Datalog and Clojure. I never got very warm with Clojure and find Datalog a little weird, so Instant‘s abstractions are highly welcome! Surely the InstantQL-Datalog translator will be usable as a separate component, this would be super useful for me.

In general, this sounds like a lot of things done right. It sounds VERY close to just what I wish existed.

I guess I understand the choice of Postgres since this seems to be primarily focused on being SaaS. It might not matter much when the backend is Clojure anyway, but an embedded database like SQLite might make it a little simpler to deploy locally.

Though, their console feels like it didn't get the love that the rest of the infra / website did.

Congrats on the 1.0 launch! I'm excited to keep building with Instant.

Also, are there plans to release SDKs in other languages (namely, Dart)?

Here is how I built it in a WUI: I sent SSE events from Server -> Client streaming web-search progress, but then the client could update a `x` box on "parent" widget using the `id` from a SSE event using a simple REST call. The `id` could belong to parent web-search or to certain URLs which are being fetched. And then whatever is yielding your SSE lines would check the db would cancel the send(assuming it had not sent all the words already).

Instant crosses that persistence boundary, your app can propagate updates to any one who has subscribed to the abstract datastore — which is on a server somewhere, so you the engineer don't have to write that code. Right?

But how is this different/better than things like, i wanna say, vercel/nextjs or the like that host similar infra?

Sending you guys lots of love and best of luck!

One of our requirements though is to be able to completely host in our own infrastructure. I know this is open source, but it would be nice if there was a simple path to self hosting.

I had a Show HN that built with Instant: https://news.ycombinator.com/item?id=44247029 The common request from that thread was to add guest auth, and few months later Instant had it baked in, so it was really easy to add that feature. Great dev experience :)

I'd just go with Rails + Postgres and have all the documentation and options open to me.

IndexDB, Postgres, Javascript, Typescript, Clojure. Not bad, but not much more attractive than the usual technology zoo any startup seems to end up with.

I see you have support for vanilla js and svelte, but it's unclear whether you can get all the same functionality if you don't use React. Is React the only first class citizen in this stack?

Are we supposed to expose all entities and relationships and rely on row level security?

Would love to check out /docs but it's currently a 404.

There is an incentive to take advantage of users ignorance rather than instruct them. There is no incentive to make self-hosting easy or secure or sustainable.

This is literally $600/month for 250GB of storage with no SLA. Cool "value add" bro.

1) Transparency on pricing: This builds confidence. Need to know exactly what I pay for additional egress/ops (read/write). "unlimited" is not sustainable for the provider (you). For example, Firestore has detailed pricing that makes scaling sustainable for them. see https://cloud.google.com/firestore/pricing.

2) Transparency on limits: Req/s, max atrributes, max value length, etc. What about querying non-local non-indexed data (e.g. via server-side call), that's costly for you guys. So, what's the limit?

3) Simpler code in the docs/examples overall. Currently, they're not bad, but not great. For example, change the "i" used everywhere to "inst" or "idb". Assume dev is a noob!

4) Change simplify/terminology used. This is probably the most important, but hardest thing. Internally, keep the same triple structure. But dev just cares about tables/key/val. Or tables+rows. Namespaces/entities are confusing. Also, be consistent/clear. For example: "Namespaces are equivalent to "tables" in relational databases"..Perhaps you meant "namespaces are just a list of tables/entities"..slighly different, but far clearer I think? "Attributes are properties associated with namespaces"...I though attributes are associated with entities? Please keep in mind, I am completely new to InstantDB, so need to study the architecture more.

5) Simplify docs BIG TIME. And add an API REFERENCE (super important). Right now, you have: Tutorials, Examples, Recipes, Docs, Essays. These are all essentially "docs".

6) Simplify the "About" section. Should be 1/10th the size. Right now, it's like a fruit salad of docs, and re-iterating the features/benefits. Instead, put pics of both founders. Maybe investor list. Pics of your office?

Your Claude Code or Codex is already an expert in all existing backends and databases, we don't need a new backend for AI.

You can literally ask Claude to pick whatever backend it thinks it best, and it will build, deploy, and work fine and be significantly cheaper than Instant 1.0.