TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: InstantDB – A Modern Firebase

1145 点作者 nezaj9 个月前
Hey there HN! We’re Joe and Stopa, and today we’re open sourcing InstantDB, a client-side database that makes it easy to build real-time and collaborative apps like Notion and Figma.<p>Building modern apps these days involves a lot of schleps. For a basic CRUD app you need to spin up servers, wire up endpoints, integrate auth, add permissions, and then marshal data from the backend to the frontend and back again. If you want to deliver a buttery smooth user experience, you’ll need to add optimistic updates and rollbacks. We do these steps over and over for every feature we build, which can make it difficult to build delightful software. Could it be better?<p>We were senior and staff engineers at Facebook and Airbnb and had been thinking about this problem for years. In 2021, Stopa wrote an essay talking about how these schleps are actually database problems in disguise [1]. In 2022, Stopa wrote another essay sketching out a solution with a Firebase-like database with support for relations [2]. In the last two years we got the backing of James Tamplin (CEO of Firebase), became a team of 5 engineers, pushed almost ~2k commits, and today became open source.<p>Making a chat app in Instant is as simple as<p><pre><code> function Chat() { &#x2F;&#x2F; 1. Read const { isLoading, error, data } = useQuery({ messages: {}, }); &#x2F;&#x2F; 2. Write const addMessage = (message) =&gt; { transact(tx.messages[id()].update(message)); } &#x2F;&#x2F; 3. Render! return &lt;UI data={data} onAdd={addMessage} &#x2F;&gt; } </code></pre> Instant gives you a database you can subscribe to directly in the browser. You write relational queries in the shape of the data you want and we handle all the data fetching, permission checking, and offline caching. When you write transactions, optimistic updates and rollbacks are handled for you as well.<p>Under the hood we save data to postgres as triples and wrote a datalog engine for fetching data [3]. We don’t expect you to write datalog queries so we wrote a graphql-like query language that doesn’t require any build step.<p>Taking inspiration from Asana’s WorldStore and Figma’s LiveGraph, we tail postgres’ WAL to detect novelty and use last-write-win semantics to handle conflicts [4][5]. We also handle websocket connections and persist data to IndexDB on web and AsyncStorage for React Native, giving you multiplayer and offline mode for free.<p>This is the kind of infrastructure Linear uses to power their sync and build better features faster [6]. Instant gives you this infrastructure so you can focus on what’s important: building a great UX for your users, and doing it quickly. We have auth, permissions, and a dashboard with a suite tools for you to explore and manage your data. We also support ephemeral capabilities like presence (e.g. sharing cursors) and broadcast (e.g. live reactions) [7][8].<p>We have a free hosted solution where we don’t pause projects, we don’t limit the number of active applications, and we have no restrictions for commercial use. We can do this because our architecture doesn’t require spinning up a separate servers for each app. When you’re ready to grow, we have paid plans that scale with you. And of course you can self host both the backend and the dashboard tools on your own.<p>Give us a spin today at <a href="https:&#x2F;&#x2F;instantdb.com&#x2F;tutorial">https:&#x2F;&#x2F;instantdb.com&#x2F;tutorial</a> and see our code at <a href="https:&#x2F;&#x2F;github.com&#x2F;instantdb&#x2F;instant">https:&#x2F;&#x2F;github.com&#x2F;instantdb&#x2F;instant</a><p>We love feedback :)<p>[1] <a href="https:&#x2F;&#x2F;www.instantdb.com&#x2F;essays&#x2F;db_browser">https:&#x2F;&#x2F;www.instantdb.com&#x2F;essays&#x2F;db_browser</a><p>[2] <a href="https:&#x2F;&#x2F;www.instantdb.com&#x2F;essays&#x2F;next_firebase">https:&#x2F;&#x2F;www.instantdb.com&#x2F;essays&#x2F;next_firebase</a><p>[3] <a href="https:&#x2F;&#x2F;www.instantdb.com&#x2F;essays&#x2F;datalogjs">https:&#x2F;&#x2F;www.instantdb.com&#x2F;essays&#x2F;datalogjs</a><p>[4] <a href="https:&#x2F;&#x2F;asana.com&#x2F;inside-asana&#x2F;worldstore-distributed-caching-reactivity-part-1" rel="nofollow">https:&#x2F;&#x2F;asana.com&#x2F;inside-asana&#x2F;worldstore-distributed-cachin...</a><p>[5] <a href="https:&#x2F;&#x2F;www.figma.com&#x2F;blog&#x2F;how-figmas-multiplayer-technology-works&#x2F;#syncing-object-properties" rel="nofollow">https:&#x2F;&#x2F;www.figma.com&#x2F;blog&#x2F;how-figmas-multiplayer-technology...</a><p>[6] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;live&#x2F;WxK11RsLqp4?t=2175s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;live&#x2F;WxK11RsLqp4?t=2175s</a><p>[7] <a href="https:&#x2F;&#x2F;www.joewords.com&#x2F;posts&#x2F;cursors" rel="nofollow">https:&#x2F;&#x2F;www.joewords.com&#x2F;posts&#x2F;cursors</a><p>[8] <a href="https:&#x2F;&#x2F;www.instantdb.com&#x2F;examples?#5-reactions">https:&#x2F;&#x2F;www.instantdb.com&#x2F;examples?#5-reactions</a>

93 条评论

jamest9 个月前
[Firebase founder] The thing I&#x27;m excited about w&#x2F;Instant is the quad-fecta of offline + real-time + relational queries + open source. The amount of requests we had for relational queries was off-the-charts (and is a hard engineering problem), and, while the Firebase clients are OSS, I failed to open source a reference backend (a longer story).<p>Good luck, Joe, Stopa and team!
评论 #41323700 未加载
评论 #41323932 未加载
评论 #41325077 未加载
评论 #41328180 未加载
评论 #41324160 未加载
评论 #41324488 未加载
评论 #41323095 未加载
评论 #41324115 未加载
sibeliuss9 个月前
One bit of feedback: Its always appreciated when code examples on websites are complete. Your example isn&#x27;t complete -- where&#x27;s the `transact` import coming from, or `useQuery`? Little minor details that go far as your product scales out to a wider user base.
评论 #41326119 未加载
评论 #41326166 未加载
评论 #41325068 未加载
评论 #41325574 未加载
codersfocus9 个月前
For those looking for alternatives to the offline first model, I settled on PowerSync. Runner up was WatermelonDB (don&#x27;t let the name fool you.) ElectricSQL is still too immature, they announced a rewrite this month. CouchDB &#x2F; PocketDB aren&#x27;t really up to date anymore.<p>Unfortunately this area is still immature, and there aren&#x27;t really great options but PowerSync was the least bad. I&#x27;ll probably pair it with Supabase for the backend.
评论 #41324132 未加载
评论 #41343353 未加载
swalsh9 个月前
I&#x27;m wary of stuff like this, probably really useful to rapidly iterate.... but what a maintence nightmare after 10 years and your schema has evolved 100 times, but you have existing customers in various state of completeness. I avoided firebase when it came out for this reason. I had a few bad experiences with maintaining applications built on top of Mongo that made it to production. It was a nightmare.
评论 #41330914 未加载
评论 #41329037 未加载
评论 #41330145 未加载
blixt9 个月前
I saw the reference to “apps like Figma” and as one of the people that worked on Framer’s (also a canvas based app) database which is also local+multiplayer I find it hard to imagine how to effectively synchronize canvas data with a relational database like Postgres effectively. Users will frequently work on thousands of nodes in parallel and perform dragging updates that occur at 60 FPS and should at least be propagated to other clients frequently.<p>Does Instant have a way to merge many frequent updates into fewer Postgres transactions while maintaining high frequency for multiplayer?<p>Regardless this is super cool for so many other things where you’re modifying more regular app data. Apps often have bugs when attempting to synchronize data across multiple endpoints and tend to drift over time when data mutation logic is spread across the code base. Just being able to treat the data as one big object usually helps even if it seems to go against some principles (like microservices but don’t get me started on why that fails more often than not due to the discipline it requires).
评论 #41326710 未加载
评论 #41331026 未加载
评论 #41351869 未加载
评论 #41329622 未加载
lewisl90299 个月前
Congrats on the launch! :)<p>Apparently I signed up for Instant previously but completely forgot about it. Only realized I had an account when I went to the dashboard to find myself still logged in. I dug up the sign up email and apparently I signed up back in 2022, so some kind of default invalidation period on your auth tokens would definitely make me a bit more comfortable.<p>Regardless, I&#x27;m still as excited about the idea of a client-side, offline-first, realtime syncing db as ever, especially now that the space has really been picking up steam with new entrants showing up every few weeks.<p>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&#x27;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.<p>Looking at the docs I&#x27;m getting the sense that there might be an assumption of 1 email per user in the user model currently. Is that correct? If so, any plans to evolve the model to become more flexible?
评论 #41325685 未加载
coffeemug9 个月前
Congrats on the launch! I think Firebase was started in 2011, and it&#x27;s incredible that 13 years later the problem is still unsolved in an open way. We took a shot at this at RethinkDB but fell short. If I were doing this again today, Instant is how I would build it. Rooting for you!
评论 #41325650 未加载
antidnan9 个月前
I&#x27;ve been using Instant for about 6 months and have been very happy. Realtime, relational, and offline were the most important things for us, building out a relatively simple schema (users, files, projects, teams) that also is local first. Tried a few others unsuccessfully and after Instant, haven&#x27;t looked back.<p>Congrats team!
评论 #41325087 未加载
breatheoften9 个月前
What&#x27;s the short summary of how the authorization system works for this?<p>One of the things I find quite nice about firebase is the quite powerful separation between the logic of data retrieval &#x2F; update and the enforcement of access policy -- if you understand it you can build the prototype on a happy path with barely any authorization enforcement and then add it later and have quite complete confidence that you aren&#x27;t leaking data between users or allowing them to change something they shouldn&#x27;t be able to. Although you do need to keep the way this system works in mind as you build and I have found that developers often don&#x27;t really grasp the shape of these mechanisms at first<p>From what I can tell -- the instant system is different in that the permission logic is evaluated on the results of queries -- vs firebase which enforces whether the query is safe to run prior to it even being executed ...
评论 #41323588 未加载
the_duke9 个月前
I&#x27;ve found triple stores to have pretty poor performance when most of your queries fetch full objects, or many fields of the same object, which in the real world seems to be very common.<p>Postgres also isn&#x27;t terrible, but also not brilliant for that use case.<p>How has your experience been in that regard?
评论 #41325803 未加载
评论 #41325106 未加载
评论 #41325400 未加载
remolacha9 个月前
I really want an ActiveRecord-like experience.<p>In ActiveRecord, I can do this:<p>```rb<p>post = Post.find_by(author: &quot;John Smith&quot;)<p>post.author.email = &quot;john@example.com&quot;<p>post.save<p>```<p>In React&#x2F;Vue&#x2F;Solid, I want to express things like this:<p>```jsx<p>function BlogPostDetailComponent(...) {<p><pre><code> &#x2F;&#x2F; `subscribe` or `useSnapshot` or whatever would be the hook that gives me a reactive post object const post = subscribe(Posts.find(props.id)); function updateAuthorName(newName) { &#x2F;&#x2F; This should handle the join between posts and authors, optimistically update the UI post.author.name = newName; &#x2F;&#x2F; This should attempt to persist any pending changes to browser storage, then &#x2F;&#x2F; sync to remote db, rolling back changes if there&#x27;s a failure, and &#x2F;&#x2F; giving me an easy way to show an error toast if the update failed. post.save(); } return ( &lt;&gt; ... &lt;&#x2F;&gt; )</code></pre> }<p>```<p>I don&#x27;t want to think about joining up-front, and I want the ORM to give me an object-graph-like API, not a SQL-like API.<p>In ActiveRecord, I can fall back to SQL or build my ORM query with the join specified to avoid N+1s, but in most cases I can just act as if my whole object graph is in memory, which is the ideal DX.
评论 #41323989 未加载
评论 #41325864 未加载
评论 #41326563 未加载
w10-19 个月前
Is the datalog engine exposed? Is there any way to cache parsed queries?<p>Other datalog engines support recursive queries, which makes my life <i>so</i> much easier. Can I do that now with this? Or is it on the roadmap?<p>I have fairly large and overlapping rules&#x2F;queries. Is there any way to store parsed queries and combine them?<p>Also, why the same name as the (Lutris) Enhydra java database? Your domain is currently listed as a &quot;failed company&quot; from 1997-2000 (actual usage of the Java InstantDB was much longer)<p><pre><code> https:&#x2F;&#x2F;dbdb.io&#x2F;db&#x2F;instantdb </code></pre> Given that it&#x27;s implemented clojure and some other datalog engines are in clojure, can you say anything about antecedents?<p>Some other Clojure datalog implementations, most in open source<p>- Datomic is the long-standing market leader<p>- XTDB (MPL): <a href="https:&#x2F;&#x2F;github.com&#x2F;xtdb&#x2F;xtdb">https:&#x2F;&#x2F;github.com&#x2F;xtdb&#x2F;xtdb</a><p>- Datascript (EPL): <a href="https:&#x2F;&#x2F;github.com&#x2F;tonsky&#x2F;datascript">https:&#x2F;&#x2F;github.com&#x2F;tonsky&#x2F;datascript</a><p>- Datalevin ((forking datascript, EPL): <a href="https:&#x2F;&#x2F;github.com&#x2F;juji-io&#x2F;datalevin">https:&#x2F;&#x2F;github.com&#x2F;juji-io&#x2F;datalevin</a><p>- datahike (forking datascript, EPL): <a href="https:&#x2F;&#x2F;github.com&#x2F;replikativ&#x2F;datahike">https:&#x2F;&#x2F;github.com&#x2F;replikativ&#x2F;datahike</a><p>- Naga (EPL): <a href="https:&#x2F;&#x2F;github.com&#x2F;quoll&#x2F;naga">https:&#x2F;&#x2F;github.com&#x2F;quoll&#x2F;naga</a>
评论 #41325168 未加载
评论 #41324370 未加载
webdevladder9 个月前
As a potential dev user this looks really intriguing, hitting all of the main points I was looking for. I build apps in this space, and the open source alternatives I&#x27;ve evaluated are lacking specifically in &quot;live queries&quot; or don&#x27;t use Postgres. The docs look great too.<p>In the docs[1]:<p>&gt; Instant uses a declarative syntax for querying. It&#x27;s like GraphQL without the configuration.<p>Would you be interested in elaborating more about this decision&#x2F;design?<p>[1] <a href="https:&#x2F;&#x2F;www.instantdb.com&#x2F;docs&#x2F;instaql">https:&#x2F;&#x2F;www.instantdb.com&#x2F;docs&#x2F;instaql</a>
评论 #41323266 未加载
remolacha9 个月前
This is awesome. I know that a lot of people are looking for something like the Linear sync engine.<p>I appreciate that you&#x27;re thinking about relational data and about permissions. I&#x27;ve seen a bunch of sync engine projects that don&#x27;t have a good story for those things.<p>imo, the more that you can make the ORM feel like ActiveRecord, the better.
评论 #41325715 未加载
TeeWEE9 个月前
Very nice!<p>However for our use case we want total control over the server database. And wanted to store it in normalized tables.<p>The solution we went for us is streaming the mutation stream (basically the WAL) from&#x2F;to client and server. And use table stream duality to store them in a table.<p>Permissions are handled on a table level.<p>When a client writes it sends a mutation to the servers. Or queues it locally if offline. Writes never conflict: we employ a CRDT “last write wins” policy.<p>Queries are represented by objects and need to be implemented both in Postgres as wel as SQLLite (if you want offline querying, often we don’t). A query we implement for small tables is: “SELECT *”.<p>Note that the result set being queried is updated realtime for any mutation coming in.<p>It’s by default not enforcing relational constraints on the clientside so no rollbacks needed.<p>However you can set a table in different modes: - online synchronous writes only: allows us to have relational constraints. And to validate the creation against other server only business rules.<p>The tech stack is Kotlin on client (KMM) and server, websocket for streaming. Kafka for all mutations messaging. And vanilla Postgres for storing.<p>The nice thing is that we now have a Kafka topic that contains all mutations that we can listen to. For example to send emails or handle other use cases.<p>For every table you: - create a serializable Kotlin data class - create a Postgres table on the server - implement reading and writing that data, and custom queries<p>Done: the apps have offline support for reading a single entity and upserts. Querying require to be online if not implemented on the client.
RoboTeddy9 个月前
(1) This is awesome. Feels like this wraps enough complexity that it won&#x27;t just be a toy &#x2F; for prototyping.<p>(2) When a schema is provided, is it fully enforced? Is there a way to do migrations?<p>Migrations are the only remaining challenge I can think of that could screw up this tool long-term unless a good approach gets baked in early. (They&#x27;re critically important + very often done poorly or not supported.) When you&#x27;re dealing with a lot of data in a production app, definitely want some means of making schema changes in a safe way. Also important for devex when working on a project with multiple people — need a way to sync migrations across developers.<p>Stuff like scalability — not worried about that — this tool seems fundamentally possible to scale and your team is smart :) Migrations though... hope you focus on it early if you haven&#x27;t yet!
评论 #41340719 未加载
taw12859 个月前
This looks fantastic. I want to recommend this to my team. We are a small consulting team building apps for clients. I have a few questions to help me pitch my team and clients better: 1. the usual &quot;vendor locked in&quot;. Is there a recommended escape hatch? 2. any big clients on this yet or at what scale do you expect people to start rolling their in house product
评论 #41325702 未加载
projektfu9 个月前
It reminds me of the data half of Meteor, but it looks better thought-out and, obv., not based on Mongo. Nice work.
评论 #41323451 未加载
monomers9 个月前
I&#x27;m missing clarity about how do I escape Instant DB when I need to, and how to make it part of a larger system.<p>Say I have an InstantDB app, can I stream events from the instant backend to somewhere else?
评论 #41331336 未加载
IanCal9 个月前
I&#x27;ve just used this to start a bouldering app, so far has been extremely simple, great work.<p>I&#x27;m not sure about how things grow from here in terms of larger aggregates and more complex queries though so am slightly worried I&#x27;m painting myself into a corner. Do you have any guides or pointers here? Or key areas people shouldn&#x27;t use your db?
评论 #41323877 未加载
评论 #41322855 未加载
the_king9 个月前
This is really cool. Curious to see more about how the database can be queried. I don&#x27;t write much SQL these days, and I have no dedication to Postgres, but it does integrate with pretty much everything. Also curious how I&#x27;d go about the basics in Instant.<p>For example, creating a user table and ensuring that emails are unique - I&#x27;ve done it 50 times with Postgres. Is that part built out yet?<p>Very cool. Appreciate the &quot;Don&#x27;t Make Me Think&quot; API.<p>(written with aqua)
评论 #41326222 未加载
cheema339 个月前
Is it correct to assume that if your existing application has lots of data stored in standard PostgreSQL tables, you can&#x27;t have InstantDB sync with it?<p>In other words it primarily targets brand new projects or projects that can completely migrate away from their current database?
评论 #41331000 未加载
kabes9 个月前
From skimming through the site, it&#x27;s not clear to me how the BE looks like. Obviously, the BE part is the hard&#x2F;interesting part. Is that open-source and&#x2F;or self deployable? Or is this fixed to a backend-as-a-service you guys provide?
评论 #41328532 未加载
评论 #41328686 未加载
评论 #41331230 未加载
ochiba9 个月前
Sounds conceptually similar to Zero: <a href="https:&#x2F;&#x2F;zerosync.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;zerosync.dev&#x2F;</a><p>I haven&#x27;t looked in detail yet — what are the main differences relative to Zero?
评论 #41356686 未加载
评论 #41324538 未加载
jeromechoo9 个月前
This is awesome. I built a real time whiteboarding app for teachers over 10 years ago on the backbone of the original Firebase service.<p>It was so fast I was able to build basic collision physics of letter tiles and have their positions sync to multiple clients at once. What a shame to be killed by Google.<p>I haven&#x27;t had a need for real time databasing since, but this is inspiring me to build another collaborative app.
评论 #41323642 未加载
mattfrommars9 个月前
I read the whole thing but I fail to understand how does this help or fit into picture of CRUD app. Most app I interact and work for a living are essentially a CRUD, SQL Server and a DOA layer by Spring.<p>How do I need to start thinking conceptually for this, InstantDB or Firebase concept to kick in?<p>Say for a collaborative text editor, I&#x27;d use off the shelf CRDT Javascript implementation.
评论 #41325765 未加载
jgeurts9 个月前
This looks great! Is there a way to sync with an api? For instance, my site currently has a rest based api with a non-Postgres backed db but I’d like to add offline, sync, real-time capabilities. Is there an option to sync the updates outside of the Postgres store?
评论 #41351933 未加载
p2hari9 个月前
I saw the mention of Google&#x27;s CEL for authorisation and permission, however would like to know a little about security. Apart from the appId, can I restrict call to db by domain etc. Firebase has protection on such things . somebody should not just take the appId and start calling db.
评论 #41331911 未加载
评论 #41331838 未加载
评论 #41326544 未加载
DandyDev9 个月前
What isn’t modern about Firebase and what makes this modern in comparison?
评论 #41323552 未加载
piyushtechsavy9 个月前
This seems like a game changer for real time applications. We have been using Firebase mostly for it RTDB and websocket kind of implementation without actually maintaining websocket at the backend. This takes things a step ahead.
koito179 个月前
The datalog syntax has me curious. It looks like a JavaScript &quot;port&quot; of Datomic&#x27;s Datalog syntax. Have you considered using other forms of Datalog that are seemingly more compatible with JavaScript? See <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Datalog?useskin=vector#Syntax" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Datalog?useskin=vector#Syntax</a><p>I wouldn&#x27;t mind using the Datalog syntax as-is since I have some experience using Clojure with Datomic, but it did surprise that someone would decide to use this syntax over a syntax used in other Datalog engines (and predating Datomic itself).
评论 #41332363 未加载
h4ny9 个月前
This is super exciting! I was literally just wondering if something like this existed a few days ago (seriously)!<p>Some super minor feedback appended. All the best with InstantDB!<p>There is a missing word in the message that appears after clicking on the &quot;Create an app&quot; button:<p>&gt; With that one-click you’ve claimed an id that you can use for storing your data. Now we&#x27;ll show you [how] to wire up your db to an app and start adding data. Check out the walkthrough below on your left with the full code and preview on the right.<p>Also on smaller screen sizes there is no left and right. :)
评论 #41330217 未加载
cheema339 个月前
I have been eyeing Electric SQL lately for developing a local-first app. How does InstantDB compare with Electric SQL?<p>Side note: Electric SQL is currently going through a rewrite, so things are a bit up in the air.
评论 #41330858 未加载
deepsun9 个月前
&gt; ... we would need a schema. But it turns out triple stores don’t need one.<p>Data always needs a schema (unless it&#x27;s random bits aka max entropy). The question is just where it&#x27;s managed and enforced.
Kiro9 个月前
How do I handle server-side logic? Let&#x27;s say I want moderation or rate limiting in the chat app example.
评论 #41327948 未加载
robinpdx9 个月前
This looks awesome and like something I could leverage on my team. I’m trying to modernize the back end of our chat service (at a large company you’ve heard about), to support real-time instead of polling and modern affordances like typing indicators, read receipts, and reactions.<p>I’ve built a prototype of a full stack using Flask + SocketIO + SQLite as well as an iOS client to prove the concept to the VPs.<p>How well do you think this can scale? Any plans to make native SDKs for iOS and Android?
评论 #41332529 未加载
agambrahma9 个月前
Interesting that this is Clojure :-)<p>Clojure + TS seems to be a good way to go, without being hung up on CLJS.
评论 #41330734 未加载
评论 #41324341 未加载
kachapopopow9 个月前
Why clojure (and by proxy Java?). I don&#x27;t have a problem with either, but it puzzles me quite a bit.<p>Why not the standard node.js with shared module? Assuming performance is not the primary goal.<p>Why not generated rust structures from model file and a rust server? Assuming performance is the primary goal.<p>Why not a jvm with a lightweight runtime? (Assuming instancing is used for scale here, a lot of wasted ram usage here)
评论 #41330987 未加载
techn009 个月前
How do you prevent the user from uploading a 5gb string to one of the fields?
评论 #41336297 未加载
mizzao9 个月前
A really exciting product from many years ago was Meteor, which included a realtime database layer on top of Mongo that facilitated many very novel realtime apps.<p>However, it didn&#x27;t scale well in terms of performance to large numbers of users.<p>Would anyone have thoughts on comparisons to Meteor?
评论 #41331607 未加载
j_san9 个月前
Is there a plan to make it self-hostable?
评论 #41331421 未加载
TripleChecker9 个月前
Congrats! BTW, we found a few typos on the site that you might want to fix: <a href="https:&#x2F;&#x2F;triplechecker.com&#x2F;s&#x2F;yyNfc1&#x2F;instantdb.com?v=wh8Jr" rel="nofollow">https:&#x2F;&#x2F;triplechecker.com&#x2F;s&#x2F;yyNfc1&#x2F;instantdb.com?v=wh8Jr</a>
评论 #41336362 未加载
terpimost9 个月前
If it&#x27;s offline where the data is stored? IndexDB?
评论 #41331355 未加载
评论 #41336309 未加载
aidos9 个月前
This looks great. We use our own version of something much more naive which allows for the various benefits you have (but yours does more). Ours is also based on Linear but we go all in on mobx like they do too. It’s a great model where we have optimistic updates and a natural object graph to work with in typescript. I’ll have a play with this to see if it could eventually be used as a replacement.<p>Noticed in your docs you say that Hasura uses RLS for permissions but that’s not true. They have their own language for effectively specifying the filters to apply on a query. It’s a design decisions that allows them to execute the same query for all connected clients at the same time using different parameters for each one.
评论 #41326383 未加载
punnerud9 个月前
Intro on X: <a href="https:&#x2F;&#x2F;x.com&#x2F;stopachka&#x2F;status&#x2F;1826674372175900724?s=46&amp;t=mnfnjms0Jwgo35Iov0GH2w" rel="nofollow">https:&#x2F;&#x2F;x.com&#x2F;stopachka&#x2F;status&#x2F;1826674372175900724?s=46&amp;t=mn...</a>
k__9 个月前
Is this similar to CouchDB&#x2F;PouchDB?<p>Can the backend be replaced?
评论 #41324439 未加载
legohorizons9 个月前
what would you say are pros&#x2F;cons vs. supabase?
评论 #41323183 未加载
samstave9 个月前
How about (inspired by another HN post) - a rebuild of a TUI for email, given how its built:<p><a href="https:&#x2F;&#x2F;blog.sergeantbiggs.net&#x2F;posts&#x2F;aerc-a-well-crafted-tui-for-email&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.sergeantbiggs.net&#x2F;posts&#x2F;aerc-a-well-crafted-tui...</a><p><a href="https:&#x2F;&#x2F;aerc-mail.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aerc-mail.org&#x2F;</a><p>It seems that building a version of this Aerc Email TUi with Instant is a completely doable?<p>Might be an interesting tutorial to build out an Instant FroBenDB (Instant is an instant Front-BackendDB :-) --- btu the txtual nature of aerc and its configs seem ripe for just bolting it to Instant.
gr4vityWall9 个月前
That strongly reminds me of Meteor. It&#x27;s crazy to think how many modern problems were solved by design there years ago.<p>I wish you the best of luck, having a real-time database on the client does make things much easier.
评论 #41325874 未加载
ripped_britches9 个月前
Please make a flutter SDK
评论 #41332006 未加载
chrysoprace9 个月前
Is it fully self-hostable? A lot of the time you have to hunt down small clauses in tools like these that state that some essential part of it can&#x27;t be self-hosted.
评论 #41325384 未加载
wheelerwj9 个月前
Is Firebase not modern anymore?<p>I think this looks like, a backend-end-in-box type of product? So that you just have to focus on front end mostly?<p>Could be cool for early stage projects.
thruflo9 个月前
Congrats to the Instant team. It’s a fantastic project. The DX is great and the engineering behind the datalog engine is really impressive.
评论 #41325144 未加载
notsahil9 个月前
Is it different than CRDTs?
avinassh9 个月前
&gt; we tail postgres’ WAL to detect novelty and use last-write-win semantics to handle conflicts<p>can you elaborate more on how you achieve this
评论 #41323072 未加载
xnx9 个月前
Seems comparable to <a href="https:&#x2F;&#x2F;pocketbase.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pocketbase.io&#x2F;</a>
评论 #41322787 未加载
评论 #41329251 未加载
评论 #41323499 未加载
sgonz9 个月前
Very cool! How does this compare to Supabase?
评论 #41323216 未加载
truetraveller9 个月前
Why would I use this over Yjs or Automerge?
评论 #41332571 未加载
dsmurrell9 个月前
I&#x27;m using Hasura connected to a postgres DB at the moment. What you have built sounds great.<p>Hasura offer a self hosted solution so that I know if they decide to close shop for whatever reason, I&#x27;m not stuck in the lurch and have to reengineer my entire solution. Do you offer this now or are you planning to?
评论 #41331956 未加载
superfunguy_949 个月前
this could be very useful for real-time, collaborative apps. Looking forward to trying in out on my next project
manx9 个月前
Looks great! How is the migration story when schema changes are needed? How do you deal with old clients?
评论 #41333043 未加载
评论 #41327627 未加载
warden_20039 个月前
Cute commit message...
h_tbob9 个月前
These ideas are cool but I wonder how security works. Do you do like rate limiting and stuff like that?
评论 #41323347 未加载
kentor9 个月前
Just replaced Firebase with this in my personal notes app. Also removed redux along the way :) This is great!!
eashish939 个月前
Hey this is great. But this should be pay per pricing model instead of $30&#x2F;month upfront. I don&#x27;t think with this pricing model it can be compete with cloudflare suite of products like durable objects, kv etc.
评论 #41332741 未加载
reichertjalex9 个月前
In case it&#x27;s helpful for anyone, I did a little write-up of my experience using Instant a couple months ago to hack together a simple weekend project: <a href="https:&#x2F;&#x2F;www.alexreichert.com&#x2F;blog&#x2F;ceramics-with-instantdb" rel="nofollow">https:&#x2F;&#x2F;www.alexreichert.com&#x2F;blog&#x2F;ceramics-with-instantdb</a><p>tl;dr -- I&#x27;m a big fan :)
aipro7789 个月前
Tailing the WAL is an interesting approach. How do you handle the potential increased load on the database from constant WAL reads?
评论 #41373287 未加载
unsupp0rted9 个月前
Congrats on the launch! It looks like all your examples are React (or Vanilla JS with a minimal implementation of reactivity).<p>Would you be able to add examples for Vue JS?
novoreorx9 个月前
I saw the `db.useQuery` function, quite good for people who are familiar with react-query, but is there a `useMutation` equivlent? It seems that `db.transact` does not return anything stateful.
评论 #41326263 未加载
yblu9 个月前
This looks awesome. Maybe a stupid question: appID is public, does it mean anyone can query everyone else&#x27;s database if they know the appID?
hardwaresofton9 个月前
Is this a drop-in, same-client-sdk alternative to firebase?<p>It seems like that’s what would do best in the marketplace… people seem to be fine with the API of firebase and just want it to be cheaper
评论 #41332082 未加载
bigblind9 个月前
This looks very cool!<p>I&#x27;m slightly worried about permissions evaluating to &quot;true&quot; if they&#x27;re not specified. I think this will lead to a lot of actions being accidentally allowed.
评论 #41336428 未加载
Chipshuffle9 个月前
I‘m wondering how this compares to convex (<a href="https:&#x2F;&#x2F;www.convex.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.convex.dev&#x2F;</a>)
评论 #41336277 未加载
buf9 个月前
Any plans to support other backends besides javascript?
评论 #41332807 未加载
serial_dev9 个月前
Do you have clients for Android, iOS, Mac apps, Flutter, Rust? If not, how hard do you think it is to implement a client for an additional language?
评论 #41323663 未加载
_kidlike9 个月前
This is awesome, and in a way the reverse of HTMX :)
评论 #41336435 未加载
jakubmazanec9 个月前
Maybe they&#x27;re aiming for different use cases, but for modern web app development I still prefer EdgeDB.
Alifatisk9 个月前
Their icon looks like fig.io but inverted
评论 #41324799 未加载
Hadriel9 个月前
I&#x27;m curious if something like this would be good for multiplayer games?
评论 #41333074 未加载
intellix9 个月前
Kind of like Horizon + RethinkDB? which sadly disappeared out of nowhere
评论 #41332954 未加载
ibash9 个月前
This looks awesome! Do you have any numbers around end-to-end latency?
charlie09 个月前
A &quot;modern&quot; Firebase? Firebase is only ~10 years old...
android5219 个月前
How is it better than firebase or Superbase ?
评论 #41332989 未加载
评论 #41323490 未加载
maninblackv29 个月前
How is async storage limit is handled ?
评论 #41336443 未加载
softlylove9 个月前
How does it compare with Liveblocks?
评论 #41332626 未加载
thomasfl9 个月前
Databases accessed directly from javascript in the browser, may change yet again how multi user webapps is being written. Looking forward to playing with InstantDb.
mr-pink9 个月前
you could call it freebase, because this is very stimulating
bpiroman9 个月前
best thing I ever did was move away from firebase
Lionga9 个月前
Would like to try this out if it had a Flutter&#x2F;Dart SDK
评论 #41333002 未加载
patrickaljord9 个月前
is the server side open source too?
评论 #41332579 未加载
otteromkram9 个月前
&gt; “Facebook and Airbnb“<p>I know it&#x27;s &quot;just a paycheck,&quot; but I despise both of these companies, so I&#x27;ll probably pass on this.<p>The usage of &quot;schlep&quot; so freely is also a bit unsettling.<p>Good luck!
pyryt9 个月前
This looks promising! Does any LLM understand Instantdb yet?
bnormative9 个月前
Thanks but no thanks. Firebase is already modern.