Will replicache be deprecated? Or continue to be developed/supported? E.g. Partial downloads aren't really necessary in our case so Zero isn't really necessary (although it is cool!).
I hesitate to use the word 'deprecated' because it means different things to different people. We'll continue supporting Replicache but won't add new features to it.
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.
> Transactional custom mutators that allow complex logic and server-side specific behavior are coming in beta.
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?
Very cool stuff! My understanding is that your closest competitor and most similar in design is InstantDB (previously discussed here [1]).
Would you mind letting us know about the differences in philosophy, architecture, and practice?
I found this tweet [1] by the OP to start answering my own question.
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.
This is huge. Looking forward to playing with it. Based on your docs it doesn't seem like there's going to be a way to run this on a free version somewhere because of the Postgres requirement right?
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.
I think there are a lot of free hosts that could work?
- 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
Those are just off the top of my head. Plus as jitl mentions you can just run the Dockerized pg in any free docker env.
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?
Whoa! Definitely give the commenting engine a try. It is insanely fast. I'm curious how it would work on my old SaaS app that had a ton of data and displayed attached PDFs (that were often scanned images of text, not the actual text) that are huge. Nice work.
