[HN Gopher] Instant 1.0, a backend for AI-coded apps
___________________________________________________________________
Instant 1.0, a backend for AI-coded apps
Author : stopachka
Score : 202 points
Date : 2026-04-09 18:30 UTC (1 days ago)
(HTM) web link (www.instantdb.com)
(TXT) w3m dump (www.instantdb.com)
| ladon86 wrote:
| Looks very nice! I'll give it a spin for prototypes.
|
| Would love to check out /docs but it's currently a 404.
| nezaj wrote:
| Docs should be working now! If anyone else has issues please
| let us know!
| chrysoprace wrote:
| Is InstantDB no longer about local-first or is the AI angle just
| a marketing thing?
| dghlsakjg wrote:
| This looks like a blog post highlighting that this can be used
| for vibecoded apps, not necessarily a pivot on the product.
| nezaj wrote:
| We built Instant to optimize for two things:
|
| We wanted to make a tool that (a) would make it easy to build
| delightful apps, and that (b) builders would find easy to use.
|
| This got us into making things that touch both local-first and
| AI.
|
| On the local-first side, we took on problems like offline-mode,
| real-time, and optimisitc updates.
|
| On the AI side, we built a multi-tenant abstraction, so you can
| spin up as many apps as you like, and focused on great DX/AX so
| agents found Instant easy to use too.
| jamest wrote:
| They actually deliver on the promise of "relational queries &&
| real-time," which is no small feat.
|
| 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.
| stopachka wrote:
| Thank you! We spent a lot of time with the demos on the home
| page, the essays page, and upgrading the docs.
|
| We're going to redesign the dashboard in the next few weeks.
|
| One interesting observation from our users: though they use the
| dashboard less in some ways (the AI agents spin up apps and
| make schema changes for them), we found people use them _more_
| in other ways. Instant comes with an Explorer component, which
| lets you query your data. We found users want to engage with
| that a lot more.
| asdev wrote:
| I wonder if people really need this. How many people are really
| building multiplayer apps like Figma, Linear etc? I'm guessing
| 99% are CRUD and I doubt that will change. Even if so, would you
| want to vendor lock into some proprietary technology rather than
| build with tried and tested open source components?
| nezaj wrote:
| For what it's worth, Instant is 100% open source!
|
| https://github.com/instantdb/instant
| stopachka wrote:
| > really building multiplayer apps like Figma, Linear
|
| I think there's two surprises about this:
|
| 1. If it was easier to make apps multiplayer, I bet more apps
| would be. For example, I don't see why Linear has to be
| multiplayer, but other CRUD apps don't.
|
| 2. When the abstraction is right, building apps with sync
| engines is easier than building traditional CRUD apps. The
| Linear team mentioned this themselves here:
| https://x.com/artman/status/1558081796914483201
| risyachka wrote:
| Yeah I kinda agree. Considering llms write most of the code
| today, the need for fancy tech is lower than ever. A good old
| crud app looks like a perfect fit for ai - its simple,
| repetitive and ai is great at sql. Go binary for backend and
| react for frontend - covers 99.9% use cases with basically zero
| resource usage. 5 usd node will handle 100k mau without
| breaking a sweat.
| stopachka wrote:
| > 5 usd node will handle 100k mau without breaking a sweat.
|
| One problem you may encounter with the 5 usd node: how do you
| handle multiple projects? You could put them all in one VM,
| but that set up can get esoteric, and as you look for more
| isolation, the processes won't fit on such a small machine.
|
| With Instant, you can make unlimited projects. Your app also
| gets a sync engine, which is both good for your users, and at
| least in our experiments, the AIs prefer building with it.
|
| And if you ever want to get off Instant, the whole system is
| open source.
|
| I still resonate with a good Hetzner box though, and it can
| make sense to self-host or to use more tried-and-true tech.
|
| For what it's worth, with Instant you would get a lot more
| support for easy projects. At least in our benchmarks, AI
| ghm2199 wrote:
| For people like me -- who are kind of familiar with how
| react/jetpack compose/flutter like frameworks work -- I recall
| using react-widget/composables which seamlessly update when these
| register to receive updates to the underlying datamodel. The
| persistence boundary in these apps was the app/device where it
| was running. The datamodel was local. You still had to worry
| about making the data updates to servers and back to get to other
| devices/apps.
|
| 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?
| stopachka wrote:
| I would say NextJS focuses a lot more on server-rendering. If
| you use the app router, the default path is to render as much
| as you can on the server.
|
| This can work great, but you lose some benefits: your pages
| won't work offline, they won't be real-time, and if you make
| changes, you'll have to wait for the server to acknowledge
| them.
|
| Instant pushes handles more of the work on the frontend. You
| make queries directly in your frontend, and Instant handles all
| the offline caching, the real-time, and the optimistic updates.
|
| You can have the best of both worlds though. We have an
| experimental SSR package, which to our knowledge is the first
| to combine _both_ SSR and real-time. The way it works:
|
| 1. Next SSRs the page
|
| 2. But when it loads, Instant picks it up and makes every query
| reactive.
|
| More details here: https://www.instantdb.com/docs/next-ssr
| nharada wrote:
| This is super cool and exactly what I've been looking for for
| personal projects I think. I wanna try it out, but the "agent"
| part could be more seamless. How does my coding agent know how to
| work this thing?
|
| I'd suggest including a skill for this, or if there's already one
| linking to it on the blog!
| nezaj wrote:
| We do have a skill!
|
| npx skills add instantdb/skills
|
| Would recommend doing `bunx/pnpx/npx create-instant-app` to
| scaffold a project too!
| LoganDark wrote:
| Can I view the source code of this skill / install it
| manually? I am incredibly not a fan of automated installers
| for this type of stuff.
| nezaj wrote:
| You can! The skill lives here
|
| https://github.com/instantdb/skills
| stopachka wrote:
| Good idea! I went ahead and updated the essay:
|
| https://github.com/instantdb/instant/pull/2530
|
| It should be live in a few minutes.
| minantom wrote:
| how is this better than vercel?
| nezaj wrote:
| Stopa answers this here
| https://news.ycombinator.com/item?id=47711254
|
| But pairing Instant with Vercel works great too! We have a
| tutorial on how you can build an app with Instant and deploy it
| to vercel here
|
| https://www.instantdb.com/tutorial
| ghm2199 wrote:
| One thing I have always wanted to do is cancel an AI Agent
| executing remotely that I kicked off as it streamed its part by
| part response(part could words, list of urls or whatever you want
| the FE to display). A good example is web-researcher agent that
| searches and fetches web pages remotely and sends it back to the
| local sub-agent to summarize the results. This is something
| claude-code in the terminal does not quite provide. In Instant
| would this be trivial to build?
|
| 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).
| stopachka wrote:
| If I understood you correctly:
|
| You kick off an agent. It reports work back to the user. The
| user can click cancel, and the agent gets terminated.
|
| You are right, this kind of UX comes very naturally with
| Instant. If an agent writes data to Instant, it will show up
| right away to the user. If the user clicks an `X` button, it
| will propagate to the agent.
|
| The basic sync engine would handle a lot of the complexity
| here. If the data streaming gets more complicated, you may want
| to use Instant streams. For example, if you want to convey
| updates character by character, you can use Instant streams as
| an included service, which does this extremely efficiently.
|
| More about the sync engine:
| https://www.instantdb.com/product/sync More about streams:
| https://www.instantdb.com/docs/streams
| shay_ker wrote:
| with a huge multi-tenant database, how do you deal with noisy
| neighbors? indexes are surely necessary, which impose a non-
| trivial cost at scale.
| stopachka wrote:
| One data structure that helps a lot is the grouped queue.
|
| I cover it in the essay here:
|
| https://www.instantdb.com/essays/architecture#:~:text=is%20t...
|
| To summarize:
|
| In places where we process throughput, we generally stick a
| grouped queue and a threadpool that takes from it. The
| mechanics for this queue make it so that if there's one noisy
| neighbor, it can't hog all the threads.
|
| There's more too (runbooks, rate limiting systems, buffers,
| isolated instances), but I thought this particular data
| structure was really fun to share.
| jvalencia wrote:
| How does security and isolation work? If someone else's account
| is compromised, how do I know I won't be? If instant is
| compromised, how do I know I won't be?
| stopachka wrote:
| If someone else's account is compromised, you would not be,
| because apps are logically separated. There would be no way for
| the compromised or uncompromised account to ever see your data.
|
| If Instant is compromised, then that's a lot more dangerous. We
| minimize this risk following security best practices: keeping
| data encrypted at rest, keeping secrets hashed at creation
| time, etc.
| oofbey wrote:
| Oh they're logically separated. Thanks for explaining that.
| Now I'm certain nothing could possibly go wrong.
|
| /s
| straygarr wrote:
| "logically separated" as opposed to "physically separated"
| (pretty rare in the Cloud world)
|
| If you want more details, read their open source codebase
| or ask them specifically what documentation would boost
| your confidence, instead of leaving snarky comments.
| saberience wrote:
| Keyword is "logically" separated here...
|
| Also no motion of data encrypted during transit.
|
| Would not use this for anything other than toy projects.
| storus wrote:
| An honest question - why would we need any frameworks at all for
| vibe coded apps? I can just tell the coding agent to use pure
| HTML5/Vanilla JS/CSS on the frontend and pure whatever on the
| backend and it would do it. No need for hundreds/thousands
| dependencies. For deployment I can ask the coding agent to do the
| same.
| stopachka wrote:
| A few reasons:
|
| 1. Unlimited projects: when you spin up traditional backends,
| you usually use VMs. It's expensive to start many of them. With
| Instant, you create unlimited projects
|
| 2. User experience: traditional CRUD apps work, but they don't
| feel delightful. I you want to support features like
| multiplayer, offline mode, or optimistic updates, you'll have
| to write a lot more custom infra. Instant gives you these out
| of the box, and the agents find it easier to write than CRUD
| code
|
| 3. Richer features: sometimes you'll want to add more than just
| a backend. For example, maybe you want to store files, or share
| cursors, or stream tokens across machines. These often need
| more bespoke systems (S3, Redis, etc). Instant already comes
| with these out of the box, and the agents know how to use them.
|
| There are a few demo sections in the post that show this off.
| For example, you can click button and you'll get a backend,
| without needing to sign up. And in about 25 lines of code,
| you'll make a real-time todo app.
| boxedemp wrote:
| >multiplayer
|
| How does it compare to photon networking? I've been using
| photon and webrtc mostly. I haven't had any issues, but I'm
| always interested in finding better solutions!
| stopachka wrote:
| Photon looks interesting! I am not too familiar with it,
| but from what I understand Photon and WebRTC are for
| communicating messages between clients. Those messages can
| be very fast, because they aren't blocked by writes to
| disk. Instant has two similar services, Presence & Streams.
| The primary sync engine is more for storing relational
| data.
| calvinmorrison wrote:
| same reasons human do. context and abstraction.
| storus wrote:
| I can get rid of irrelevant abstraction bloat that way and
| make code perfectly tailored for what is needed. This was
| traditionally expensive which led to abstraction being
| packaged in frameworks.
| IncreasePosts wrote:
| You don't necessarily, but each token costs money for the AI to
| spit out. And probably more money when that output is used as
| input later. Delegating to a library makes sense financially.
| storus wrote:
| With local inference on pretty decent local models we have
| nowadays (Qwen-3.5 and better) it's not much of a concern
| anymore.
| Bishonen88 wrote:
| what percentage of people is using local models for
| anything serious? I reckon single digits if even that. And
| for a corporate work environment, probably close to 0.
| walthamstow wrote:
| Sure, if you've got a PS5k laptop
| IncreasePosts wrote:
| Sure it is - there's still an opportunity cost of spending
| tokens(time/energy) creating a library from scratch vs
| using a preexisting well understood API.
| debazel wrote:
| My experience with actually trying this is that current LLMs
| benefit greatly from having a framework to build on.
|
| More code in the context window doesn't just increase the cost,
| it also degrades the overall performance of the LLM. It will
| start making more mistakes, cause more bugs, add more
| unnecessary abstractions, and write less efficient code
| overall.
|
| You'll end up having to spend a significant amount of time
| guiding the AI to write a good framework to build on top of,
| and at that point you would have been better off picking an
| existing framework that was included in the training set.
|
| Maybe future LLMs will do better here, but I wouldn't recommend
| doing this for anything larger than a landing page with current
| models.
| fny wrote:
| Why not code in assembly?
|
| I kid but any reason you can think of applies to app
| development too.
|
| 1. Good abstractions decrease verbosity and improve
| comprehension
|
| 2. Raw HTML/CSS/JS are out of distribution just like assembly
| (no one builds apps like this)
|
| 3. Humans need to understand and audit it
|
| 4. You'll waste time and tokens reinventing wheels
|
| This inuitively makes sense. LLMs mimic human behavior and
| thought, so for all the reasons you'd get lost in a pile of web
| spaghetti or x86, so would an LLM.
| monooso wrote:
| > Raw HTML/CSS/JS are out of distribution just like assembly
| (no one builds apps like this)
|
| Plenty of people build apps with vanilla CSS and JS (and HTML
| is just HTML). It's a really nice way to work.
|
| Here are a few links to get you started.
|
| https://dev.37signals.com/modern-css-patterns-and-
| techniques...
|
| https://simonwillison.net/2025/May/31/no-build/
|
| https://bradfrost.com/blog/post/raw-dogging-websites/
| solumos wrote:
| Plenty of people, but how many companies?
|
| Plenty of people bake bread from scratch without a mixer,
| but few (if any) bakeries do.
| ehnto wrote:
| Echoing other thoughts here but also, it's like getting your
| first 10,000+ lines of output code for 0 token cost, and no
| prompting effort, no back and forth or testing etc.
|
| Just jump straight to business logic, scaffolding is done for
| you already.
|
| I think in your question as well is an idea that apps from now
| on will be bespoke, small and unique entities but the truth is
| we are still going to be mostly solving already solved
| problems, and enterprise software will still require the same
| massive codebases as before.
|
| The real win of frameworks is they keep your workers, AI or
| human, constrained to an existing known set of tools and
| patterns. That still matters in long term AI powered projects
| too. That and they provide battle hardened collection of
| solutions that cover lots of edge cases you would never think
| to put in your prompts.
| Scholmo wrote:
| Its build in guard rails.
|
| Its potentially also reduced context it has to know.
|
| Its also a very good way to scale. Lets build a very small and
| well tested library for x, llm uses x for case y. it doesn't
| have to worry about x, its content, its security.
| bdcravens wrote:
| It probably has more to do with the body of knowledge it draws
| on than the suitability. I assume it burns more tokens to stay
| vanilla, as more effort is involved in implementing patterns
| more readily available "off the shelf".
| gervwyk wrote:
| simple. you reduce the surface that you need to manage and
| shift that responsibility to the framework.
|
| choose a good one and your can save you and your llms 1000s of
| decisions and future maintenance overheads.
|
| frameworks exists because they scale.
| insane_dreamer wrote:
| validation -- you're using already validated components instead
| of relying on the LLM to create them and ensure they are
| validated
| rylan-talerico wrote:
| congrats!
| nezaj wrote:
| Thank you!
| singpolyma3 wrote:
| Seems like a supabase competitor?
| stopachka wrote:
| That's a fair statement! I would say we are similar to supabase
| in that we offer a relational backend. We are different in two
| ways:
|
| 1. Supabase runs on VMs, so only supports 2 free projects. We
| built the backend to be multi-tenant, so we can give you
| unlimited free projects.
|
| 2. Supabase doesn't support offline mode or optimistic updates.
| Instant gives you a sync engine which does.
| pugio wrote:
| Thanks, this might be exactly what I'm looking for.
|
| 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?
| stopachka wrote:
| Thank you.
|
| > Is React the only first class citizen in this stack?
|
| Each system gets the same functionality. We centralize the
| critical logic for the client SDK in "@instantdb/core". React,
| Svelte, Tanstack, React Native et al are wrappers around that
| core library.
|
| The one place where it's lacking a bit is the docs. We have
| specific docs for each library, but a lot of other examples
| assume React.
|
| We are improving this as we speak. For now, the assumption on
| React is quite light in the docs, so it's relatively
| straightforward to figure out what needs to happen for the
| library of your choice.
| truetraveller wrote:
| Moose here, congrats! This is the real "firebase alternative",
| not Supabase. Supabase is good, but it's just hosted Postgres +
| user login. People who are asking "why would I need this" don't
| get how difficult scalable data storage is with user permissions.
| Would absolutely recommend this if it's good. Been in this space
| for ~7 years, and made a high-perf realtime DB as well. Will
| contact you guys directly. Some concerns for everyone's benefit:
|
| 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?
| nezaj wrote:
| Thank you for the deep feedback Moose!
|
| Agreed lots of opportunity for simplification. There's so much
| context in this space.
|
| When talking about why sync we mention optimistic updates,
| multiplayer, and offline mode. To motivate the complexity of
| sync we talk about websockets, optimistic queues, and
| IndexedDB. To explain how we work we talk about triples,
| datalog, and CTEs.
|
| We try to give a clean interface so devs don't need to worry
| about this complexity, but yea it's been an ongoing iteration
| to make both easier and transparent to understand!
| zbiggistardust wrote:
| What's the difference between Instant and Convex?
| stopachka wrote:
| I would say:
|
| We both offer a real-time queries out of the box. I am not 100%
| sure, I but think Convex also set up a multi-tenant database;
| so they can offer a good number of free projects well.
|
| The way I would differentiate Instant:
|
| With Convex you write your queries as Javascript functions.
| This means you have to do joins for example imperatively. With
| Instant, you can write queries declaratively.
|
| As of today Convex doesn't work offline, and you have to write
| optimistic updates manually. Instant can run offline and comes
| with optimistic updates out of the box.
|
| Both Convex and Instant support files out of the box. But with
| Instant you can write CASCADE delete rules, and you also get
| other services, like presence and streams.
| taoh wrote:
| Congratulations on your launch! 4 years of work is certainly
| remarkable perseverance.
|
| The sync engine feature looks very interesting to me. There
| have been quite a few products available on the market today,
| but none has achieved a dominant share yet. So if this is
| your main strength, I'd like to see more demos built local
| first.
|
| Curious if you considered shipping the engine itself as a
| standalone infra piece.
| stopachka wrote:
| Thank you.
|
| > Curious if you considered shipping the engine itself as a
| standalone infra piece.
|
| We are thinking about supporting something like "Bring Your
| Own Postgres", which would allow folks to opt into just the
| sync engine piece.
|
| Right now we focused on the integrated system, because we
| really wanted to optimize for a delightful developer
| experience on greenfield projects.
| yoavshai wrote:
| For me (and please correct me if I'm wrong, Instant team) the
| largest difference and a major source of frustration in trying
| Instant is that you don't have a backend. You get a real-time
| database with RLS and a sync engine. You don't get to run
| business logic. You don't get to write queries by name and gain
| the ability to migrate the schema as long as the query shapes
| match.
| stopachka wrote:
| If by backend you mean functions, you are right, we don't
| support this just yet! We give you an Admin SDK, which you
| can run in frameworks like NextJS, or inside systems like CF
| workers. We are definitely thinking about bringing this as a
| first-class citizen.
| satvikpendem wrote:
| Convex is not relational
| owenthejumper wrote:
| This is basically a fancy Pocketbase / Supabase?
| stopachka wrote:
| > Supabase
|
| We are similar to supabase in the sense that we support a
| relational database. We're different in that with us, you get
| real-time queries, offline mode, and optimistic updates out of
| the box.
|
| > Pocketbase
|
| I am not too familiar with Pocketbase.
| nezaj wrote:
| We think this is an evolution :)
|
| Stopa also gave an answer here!
| https://news.ycombinator.com/item?id=47711866
| nl wrote:
| What does "X Team Members per app" mean? Is this the number of
| users you can have registered or does "Team Member" have special
| meaning?
| nezaj wrote:
| You can think of this as the number of devs. So if you're
| working on an app as a team you all can use the dashboard and
| CLI tools to manage the app.
|
| No limit on number of end users for what you build
| nl wrote:
| Thanks, that's great. Congrats on the launch.
| jgeurts wrote:
| Is there a way to pair this with an existing (Postgres) database?
| nezaj wrote:
| Not at the moment but something that we've started exploring!
|
| Our thinking was to first get the DX/AX + feature set solid
| with Instant and then let folks bring their own Postgres
| dalmo3 wrote:
| Congrats on the launch!
|
| 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.
| stopachka wrote:
| Thank you for the kind words.
|
| > AI emphasis
|
| It's not quite marketing or a pivot. We've just noticed that
| most of our users are coding with AI, and really optimized for
| that too.
| nezaj wrote:
| Thank you!
|
| We last updated our website when open sourced back in August
| 2024 https://news.ycombinator.com/item?id=41322281
|
| Back then most folks weren't building full-on apps with AI yet.
|
| Since then we've seen a large number of people find us through
| content on creating apps with AI. We felt our previous
| messaging didn't speak to that and we thought it was time for a
| refresh.
|
| We also invested a lot to make the agent experience with
| Instant a delight!
| aboodman wrote:
| Congrats, Instant team. Genuinely happy for y'all.
| nezaj wrote:
| Thank you! Awesome work with Zero, been a fan of you since
| listening to your episode on the local first podcast!
| d0100 wrote:
| Any example more complex in the backend?
|
| Are we supposed to expose all entities and relationships and rely
| on row level security?
| stopachka wrote:
| > Any example more complex in the backend?
|
| The home page has some examples of complex startups that use
| Instant as their core infra:
|
| https://www.instantdb.com/#:~:text=Startups%20love%20Instant
|
| > Are we supposed to expose all entities and relationships and
| rely on row level security?
|
| Yes. This may feel foreign, but we think it's one the best ways
| to do permissions. We were originally inspired by Facebook's
| EntPrivacy. When you have permissions at the object layer, you
| can be more confident that _any_ query you write would be
| allowed.
| kenrick95 wrote:
| Congrats on the 1.0 milestone!
|
| 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 :)
| stopachka wrote:
| Brightened reading this, and the whole team was rooting you on
| for your Show HN!
| seyz wrote:
| Nice launch! It reminds me a lot RootCX
| (https://github.com/RootCX/RootCX)
| satvikpendem wrote:
| Conflict resolution for real time simultaneous updates, how do
| you resolve them? I use a CRDT for solving precisely this problem
| but seems like most multiplayer database services don't actually
| handle this correctly, using last write wins instead.
| nezaj wrote:
| We use LWW on the attribute level which greatly reduces
| conflicts. There are certainly cases where you'll need a
| different CRDT but this works great for a lot of use cases.
|
| Including Figma! https://www.figma.com/blog/how-figmas-
| multiplayer-technology...
| mohsen1 wrote:
| Congratulations on this launch. Stepan and his cofounder have
| been working on this for years and great to see it being launched
| finally. I should be building something fun with this.
|
| Sending you guys lots of love and best of luck!
| nezaj wrote:
| Thank you!
| 2001zhaozhao wrote:
| Wow, the demo-in-a-blogpost is really impressive.
| nezaj wrote:
| Appreciate it! We thought it was a nice touch too and a fun way
| to highlight the power of Instant!
|
| Realizing we didn't highlight this as a use case -- but you can
| use our ephemeral app feature (it's free) to easily add your
| own interactive demos into essays!
| tarcon wrote:
| Do we really have no way to build this in a single programming
| language and base database?
|
| IndexDB, Postgres, Javascript, Typescript, Clojure. Not bad, but
| not much more attractive than the usual technology zoo any
| startup seems to end up with.
| mentalgear wrote:
| No e2e encryption and no p2p is a deal breaker for me.
| vincnetas wrote:
| Can i selfhost?
| nezaj wrote:
| You can! Everything is open source and we have instructions on
| running the server with docker.
|
| Working on making this even easier for folks
| https://github.com/instantdb/instant/pull/2495
| rock_artist wrote:
| Apologies if it's due to lack of understanding from my end. But
| why is it 'for AI-coded'?
|
| 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?
| rambrrest wrote:
| Sounds backward to me - why would you need a backend for AI coded
| apps - if you create a new backend - you also have to 'teach' the
| LLM how to use it - how do you imagine doing that ?
| nezaj wrote:
| We've been around long enough that the LLMs already natively
| know how to use us!
|
| If you give them a little bit of context they can use the
| platform fully.
| solarkraft wrote:
| What a delightful demonstration. The AI hook is brilliant, but
| under-explained. I expected a paragraph on how to quickly get
| running with my assistant (edit:
| https://www.instantdb.com/tutorial seems to be that, though it
| focuses on using the SaaS and creating an account).
|
| 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.
| dewey wrote:
| Maybe I'm missing something, but wouldn't using the most popular
| open source framework + most popular open source database be a
| much better fit as there's much more training data and you don't
| lock yourself into yet another framework?
|
| I'd just go with Rails + Postgres and have all the documentation
| and options open to me.
| stingraycharles wrote:
| This is exactly it, and people trying to invent these new tools
| and formats (wasn't there a "LLM optimized JSON alternative the
| other day) are seriously not understanding how LLMs are trained
| a tremendous amount on understanding JSON and XML and standard
| tools and frameworks.
| patwolf wrote:
| I'm currently working on an app that needs offline support, and I
| wish I had something like this when I started.
|
| 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.
| nezaj wrote:
| PR in progress!
|
| https://github.com/instantdb/instant/pull/2495
| sbochins wrote:
| This like many other attempts at this type of thing don't
| understand the in distribution vs out of distribution aspect of
| ml models. Using something the model has the most training on
| will have the best outcomes. A new handcrafted programming
| language will perform significantly worse than a poorly thought
| out programming language that is widely used. Everything is going
| to revert to the mean as llms continue to progress.
| scoopdewoop wrote:
| Man, its hard not to have a reaction to another BaaS. Every
| "pricing" page really goes to show that engineering took a
| backseat to rent-seeking.
|
| 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.
| nezaj wrote:
| We're 100% open source and have instructions for getting the
| server up and running via docker
|
| We're also working on a PR to make it even easier to deploy
|
| https://github.com/instantdb/instant/pull/2495
| saberience wrote:
| Wait, why is this needed at all? Why is this backend AI specific?
|
| 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.
| nezaj wrote:
| I think Stopa has a great answer here
| https://news.ycombinator.com/item?id=47711803
|
| You can certainly use Instant without AI! We indexed on making
| the API easy to understand so projects built with Instant are
| easy to maintain. We also invested in our AX experience since
| we saw more folks coming to us when trying to build apps with
| AI
| raffaeleg wrote:
| The "predefined patterns reduce token costs" framing resonates.
| We saw the same thing building empla.io. Every time we left a
| backend decision open to the agent, it burned 3x to 4x the tokens
| exploring before committing. The counterintuitive part is that
| declarative query languages save more tokens than they save for
| humans, because the agent does not have to plan imperative
| control flow step by step. Two open questions for the Instant
| team. How are you handling schema evolution when an agent decides
| mid-session that it needs a new relation? That is exactly where
| Supabase falls over for us. And do you expose a cost budget
| primitive per session, or does the user have to instrument that
| separately?
| chabad360 wrote:
| This seems really cool, I've used Pocketbase before for similar
| purposes, the only thing it doesn't offer is local-first (which
| is a bit of a bummer). But one very valuable feature it has is
| server extensibility. You can write server hooks in JS and Go
| (it's embeddable as a Go module) to add features you need. For
| example, in a previous project, I added functionality to send
| push notifications based on certain user actions. Is this kind of
| thing possible in InstantDB? Or, would I need to build a worker
| that listens for those events and fires off the notification on
| its own?
|
| Also, are there plans to release SDKs in other languages (namely,
| Dart)?
| nezaj wrote:
| You can use `db.subscribeQuery` on the server to react to react
| to changes. We plan to add webhooks soon to make this even
| easier. And yes eventually we'd love to support SDKs in other
| languages too!
___________________________________________________________________
(page generated 2026-04-10 23:01 UTC)