Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: InstantDB – A Modern Firebase

github.com

Post reply on HN
Print view View original

251–260 of 308 posts

Re: Show HN: InstantDB – A Modern Firebase

#251

Post by stopachka »

cheema33 wrote: post #225
cheema33 wrote: post #88

I have been eyeing Electric SQL lately for developing a local-first app. How does InstantDB compare with Electric SQL? Side note: Electric SQL is currently going through a rewrite, so things are a bit up in the air.

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

> standard PostgreSQL tables

We're working on a feature where you bring an existing Postgres database, and use Instant as the sync layer [1]. If you have an app like this and would be interested in beta testing, let us know: founders@instantdb.com

[1] For a peak, you can search for 'byop' in the codebase. Here's a fun introspection query, which definitely awed me about Postgres' powers: https://github.com/instantdb/instant/blob/main/server/src/in...

Re: Show HN: InstantDB – A Modern Firebase

#252

Post by stopachka »

robinpdx wrote: post #27

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. 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. How well…

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.

Re: Show HN: InstantDB – A Modern Firebase

#253

Post by stopachka »

serial_dev wrote: post #83
stopachka wrote: post #45

Earlier quoted context omitted.

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

So if I understand it right one option you seriously consider is... after the JS client feels right, you write a "core" language in C/Rust/Zig, then "wrap" it with Swift, Kotlin, and Dart?

Yes. for more context:

Right now because our client SDKs are in JS, we can share much of the logic between React Native, React, and vanilla JS.

If we were to add native client SDKs, we'd have to duplicate the logic across different languages. One alternative path could be to write some shared code in a core language.

This idea is not set in stone at all though, I just enjoyed Mitchell's experience report.

Re: Show HN: InstantDB – A Modern Firebase

#254

Post by stopachka »

truetraveller wrote: post #144

Why would I use this over Yjs or Automerge?

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

Re: Show HN: InstantDB – A Modern Firebase

#256

Post by stopachka »

softlylove wrote: post #119

How does it compare with Liveblocks?

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"

Re: Show HN: InstantDB – A Modern Firebase

#257

Post by nezaj »

eashish93 wrote: post #197

Hey this is great. But this should be pay per pricing model instead of $30/month upfront. I don't think with this pricing model it can be compete with cloudflare suite of products like durable objects, kv etc.

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.

Re: Show HN: InstantDB – A Modern Firebase

#260

Post by d0100 »

jitl wrote: post #127
the_duke wrote: post #75

I'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. Postgres also isn't terrible, but also not brilliant for that use case. How has your experience been in that regard?

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…

I really love Postgres, but I'll never not laugh at the fact that duplicating a CTE caused my query to go faster... (60s to 5s)

Postgres really trips up when you start joining tables

Sometimes you can fix it with "(not) materialized" hints, but a lot of the time you just have to create materialized views or de-normalize your data into manual materialized views managed by the application

Post reply on HN