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