When To Use Zero

We are trying to make Zero a great choice for a wide variety of applications. But every tool has tradeoffs, and Zero especially so while in alpha.

This page will help you understand if Zero is a good fit for you today.

Zero Might be a Good Fit

You want to sync only a small subset of data to client

Zero's query-driven sync is a powerful solution for partial sync. You can sync any data you can express as a set of Zero queries. By using partial sync, Zero apps can commonly load in < 1s, yet still maintain the interaction perf of sync.

You need fine-grained read or write permissions

Zero's custom mutators allow you to run arbitrary authorization, validation, or business logic on the write path. You can enforce that a write depends on what group a user is in, what has been shared with them, their role, etc. Read permissions are very expressive, allowing similar control over what data is synced to the client.

You are building a traditional client-server web app

Zero was designed from the ground up to be as close to a classic web app as a sync engine can be. If you have a traditional web app, you can try Zero side-by-side with your existing REST or GraphQL API, and incrementally migrate over time.

You use PostgreSQL

Some tools in our space require you to use a non-standard backend database or data model. Zero works with PostgreSQL, and uses your existing schema.

Your app is broadly "like Linear"

Zero is currently best suited for productivity apps with lots of interactivity.

Interaction performance is very important to you

Zero was built by people obsessed with interaction performance. If you share this goal you'll be going with the grain of Zero's design choices.

Zero Might Not be a Good Fit

You need the privacy or data ownership benefits of local-first

Zero is not local-first. It's a client-server system with an authoritative server.

You need to support offline writes or long periods offline

Zero doesn't support offline writes yet.

You are building a native mobile app

Zero is written in TypeScript and only supports TypeScript clients.

The total backend dataset is > ~1TB

Zero stores a replica of your database (at least the parts that can sync to client) in a SQLite database stored on attached SSD within the Zero server. The ultimate limit of this database size is the size of attached SSD. But 1TB is a reasonable practical limit today.

Zero Might Not be a Good Fit Yet

While Zero is in alpha, there are additional reasons not to choose it:

You don't want to run server-side infra

Zero is a Docker container that you currently have to self-host. We're working on a SaaS solution but it's not ready yet.

You can't tolerate occasional downtime

The easiest way to run Zero today is single-node, which requires downtime for updates. Also there are occasional regressions.

You need immediate support for React Native

Zero doesn't support React Native yet, but it is planned.

You need support for SSR

Zero doesn't support SSR yet, but it is planned.

Alternatives

If Zero isn't right for you, here are some good alternatives to consider:

• Automerge: Local-first, CRDT-based solution. Pioneering branch-based offline support.
• Convex: Not a sync engine (reads and writes are server-first), but a very nice reactive database that is in GA.
• Ditto: CRDT-based, with high quality offline support.
• Electric: Postgres-based sync engine with a SaaS cloud.
• LiveStore: Interesting event sourced design from one of the founders of Prisma.
• Jazz: Batteries-included local-first.
• PowerSync: Sync engine that works with Postgres, MySQL, and MongoDB.