Live data from Hacker News

Show HN: InstantDB – A Modern Firebase

github.com

301–308 of 308 posts

Re: Show HN: InstantDB – A Modern Firebase

#301
post #155

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 propag…

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

Re: Show HN: InstantDB – A Modern Firebase

#302

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?

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?

Re: Show HN: InstantDB – A Modern Firebase

#303
post #69

Sounds conceptually similar to Zero: https://zerosync.dev/ I haven't looked in detail yet — what are the main differences relative to Zero?

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.

Re: Show HN: InstantDB – A Modern Firebase

#305

For those looking for alternatives to the offline first model, I settled on PowerSync. Runner up was WatermelonDB (don't let the name fool you.) ElectricSQL is still too immature, they announced a rewrite this month. CouchDB / PocketDB aren't really up to date anymore. Unfortunately this area is still immature, and there aren't really great options but PowerSync was the least bad. I'll probably pair it with Supabase…

> 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?

The biggest "source" of vibes that CouchDB/PouchDB is "dead/maintenance mode" is the corporate ecosystem/contributors around it:

- Couchbase has been increasingly moving away from CouchDB compatibility

- Cloudant was one of the more active contributors until it got eaten by IBM and put into a maintenance spiral (what mother can love what IBM "Blue Mix" has done to Cloudant?)

- In general the still growing number of document DBs that are Mongo-compatible but not CouchDB-compatible (AWS and Azure document DB offerings, for instance)

In Open Source the winds of commercial favor aren't always reflective of Open Source contributor passion, but there too the pace of PouchDB seemed to greatly slow down a few years ago, and lost the interest of some major contributors. CouchDB itself seems to have gotten hugely stuck in a bunch of Apache committees over the design of the next semver major version, with a ton of huge breaking changes that don't really seem to be for solving problems but do some architecture battle under the hood, some political war between Erlang and other programming languages for superiority, and some political war between Apache trying to consolidate core functionality with some of the other database-like engines in their ~~graveyard~~ custodianship.

Re: Show HN: InstantDB – A Modern Firebase

#306

Tailing the WAL is an interesting approach. How do you handle the potential increased load on the database from constant WAL reads?

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...

Re: Show HN: InstantDB – A Modern Firebase

#307

Earlier quoted context omitted.

Thanks for the response. 2 questions. How hard is it to swap our firebase for instant? I've had an amazing time with firebase, but I sorta want to switch to using a completely local solution. I have a small lyric video generator, and while I don't care about my own songs potentially leaking, I would never want to take responsibility for something else's data. I basically use firebase for the lyrics afterwards I trans…

Glad I could be helpful. > How hard is it to swap our firebase for instant? I've had an amazing time with firebase, but I sorta want to switch to using a completely local solution. It should be relatively straightforward to switch. If you have any questions, you could always reach to us on Discord [1] The only caveat though: Instant is like Firebase; it is not a completely local solution. If you are worried about exp…

> Instant is like Firebase; it is not a completely local solution. If you are worried about exposing some data over the internet, I would store the same kind of stuff you were thinking about with Firebase.

What does this mean exactly? If you host your own it is still not local?

Post reply on HN