Even if you don't think you'll need partial sync our experience is that almost all projects end up needing either it or permissions. Both of which are difficult with Replicache.
And if you don't need either of those, the the query-based programming model of Zero is just a lot more fun.
In short, while both InstantDB and Zero use PostgreSQL as a backend (and add a subscription mechanism in front), the former uses it as a triple store (more similar in practice to something like Triplit), meaning the data is not available in a format comprehensible to other clients, so it is merely an implementation detail. Zero however allows the database to be accessed simultaneously in other manners, promoting compatibility and reducing lock-in.
Top-level response: I think Instant is very cool and I have a lot of respect for that team and their work. I've tried to be accurate below, but I know the instant folks frequent HN so maybe they can chime in too and correct anything I've gotten wrong.
1. Instant is a full database, including the backend. Zero is not - it connects to some separate authoritative backend db. Currently only Postgres is supported, but our intent is to support other DBs like MySQL, Mongo, Cockroach, and in the fullness of time even custom distributed systems. Zero's "BYODB" approach has some advantages:
* You don't have to trust us to build a correct backend database (nothing Zero can do can corrupt your data - it's just a fancy cache)
* If you end up not liking Zero you can easily move to anything else that can run on top of PG.
* You can adopt Zero incrementally in an existing project by just moving features over to Zero one-by-one.
* Any code, library, or project that works with PG likely already works with Zero.
* Zero can coexist with other types of PG users. If some non-Zero client changes PG, Zero clients will see it update live. If Zero clients change PG, other clients will see it when they next read PG.
* You don't have to wait for us to build features. Admin UI? Use any of the great PG ones. Data export? It's just PG. Backups? Triggers? FKs? Constraints? Schemas? Migrations? Use all the normal PG stuff.
On the flip side this is a more complicated way to build the system and some of that complexity does leak out into Zero's DX. We're trying to minimize it as best we can, but Zero can probably never be quite as 'sleek' an experience as Instant.
2. Instant uses a datalog/triple style data model and a custom query system. Zero's data model is just relational data, and it uses a SQL-style query system. In practice the API that instant exposes is very relational-like, but I still think that if you know SQL already there's less to learn with Zero.
3. Zero is based on Incremental View Maintenance. When data that affects a Zero query changes, Zero does only a small amount of work to reflect the change. To my knowledge, Instant doesn't do this and re-runs the query (correct me if I'm wrong here Instant folks). This was a specific design choice in Zero because ...
4. Zero was designed primarily to support 'the linear use case': storing dozens of MB of data client-side and keeping it up to date with permissions and partial sync. We did not want to have to run these huge queries over and over.
5. Zero is very focused on just being a sync engine. Instant appears to be aiming to take on more of the suite of features Firebase offers like login, email, blob storage, etc.
6. Instant already has a SaaS live, Zero doesn't.
Any thoughts on if SQLite would be suitable and likely to be supported in the future? That would make this really perfect getting a MVP going.
- Fly.io has a free tier that has postgres (if you want to debug from your workstation against live pg, which is useful, it's $2/mo for a public IP)
- Supabase has a free tier (with the caveat that schema changes will resync the replica - which is fine as long as db is smallish)
- AWS/RDS offers one year free
zero-cache and Postgres both will run for free on your local machine in docker. If you want to run zero-cache for free in the cloud, you can probably run Postgres for free in the cloud in the same way.
zero-cache uses SQLite internally, but the component that’s missing for SQLite support overall is a replication log that zero-cache can subscribe to.
Or are you imagining zero-cache itself as the DB of record?
It seems right now it only supports CRUD-style logic? Suppose I have a Go backend service (or any other language, really). Creating and exposing some pg tables for the read only path is something reasonable if I want to integrate with zero.
But what about the write path in such an app? Where you have some business logic that doesn't involve simple CRUD, will (or does) zero support that with custom mutators?
edit: I didn't see this notion page which address this https://replicache.notion.site/Introducing-Zero-8ce1b1f184aa...
It's insanely fast. And wholeheartedly recommend this wonderful talk about the thoughts that led to this:
Awesome Work, congratulations on the alpha launch!
excited to build something with this!