Show HN: InstantDB – A Modern Firebase

Original Article ↗ Hacker News Discussion ↗

Positioning vs. Firebase / Supabase / Others

  • Framed as “relational Firebase”: same offline + realtime feel, but with relations and more expressive queries.
  • Compared to Firebase:
    • Firebase’s document model makes joins and schema evolution painful; people report hand-rolled joins, duplication, and pricing issues from many reads.
    • Instant aims to fix this via relational data on top of Postgres, while still doing optimistic updates and offline.
  • Compared to Supabase / Hasura / Convex:
    • Those give Postgres + APIs, but don’t natively offer offline/optimistic/live-query behavior at the client.
    • Instant runs queries and transactions on the client, tries to give “Linear/ActiveRecord-like” DX.
  • Also compared to PocketBase, ElectricSQL, Liveblocks, Meteor, Replicache/Zero, CouchDB/PouchDB; Instant is seen as in the same “local-first, realtime” space but with a different architecture.

Architecture, Query Model, and Permissions

  • Uses a triple-store layer on Postgres plus Datalog-style queries; front-end queries are JS data structures (“GraphQL without the schema/strings”).
  • Live queries are powered by tailing Postgres WAL; changes map to “topics” which invalidate and refresh subscribed queries, inspired by LiveGraph/Luna.
  • Permissions built on Google’s CEL:
    • Per-object rules for view/create/update/delete.
    • Currently evaluated after queries; plan is to push rules into SQL (RLS-like) for efficiency.
    • Default “allow if unspecified” worries some; maintainers are considering safer defaults.

Offline, Caching, and Storage

  • Clients keep a partial replica of queried data in IndexedDB and support optimistic updates and offline queues.
  • IndexedDB’s storage limits and eviction behavior are acknowledged; Instant is positioned as “hybrid offline,” not a pure offline DB.
  • For purely local apps, several commenters recommend SQLite instead.

Performance, Scalability, and Data Model Concerns

  • Some skepticism about triple-store performance and EAV-like schemas in Postgres; others note it’s probably fine for MVP/hosted usage.
  • Team mentions batching updates and possible evolution toward Tao-like structures or a direct Postgres-table adapter.
  • A Postgres adapter (“bring your own Postgres”) is in active development to sync against existing relational schemas.

Ecosystem, DX, and Open Questions

  • Server is fully open source and self-hostable; no private repos. Admin SDK and HTTP API act as escape hatches for custom logic/migrations.
  • Currently JS/React/React Native only; many requests for Flutter, native mobile, and other languages.
  • Users report very positive DX (simple live queries, easy prototypes, replacement for Firebase + Redux), but:
    • Migrations are still mostly manual via admin scripts.
    • Rate limiting, complex moderation logic, and security features like domain restrictions are incomplete or planned.
  • Overall sentiment: highly enthusiastic about the concept and execution so far, tempered by concerns about long-term performance, permissions safety, and migration/maintenance story.