Hah, funny to see this reposted – I'm the author.

We've had great success with Replicache+Orama since this was written. We're keen to give Zero a spin once it's a bit more stable.

Triplit has essentially folded as a "company" and become some sort of open-source initiative instead.

InstantDB has matured massively and is definitely worth a look for anyone starting a new project.

▲

local_surfer 4 days ago | parent | next [-]

Orama is definitely a hidden gem, and it's a clever usage for complementary indexing!

Also agreed Triplit's DX is excellent. I'd recommend giving it another look, Triplit's recent 1.0 release has up to 10x performance boost (https://www.triplit.dev/blog/triplit-1.0).

Since your use-case is data in the range of gigabytes, you could consider using duckdb-wasm. However I'm not sure how to best integrate this with collaboration / CRDTs (sqlRooms is also interesting prior art).

	▲	isaachinman 2 days ago \| parent [-]
		Yeah, I spent quite some time researching nearly all indexing options. Orama is in a different league (although it does have some warts). We have hundreds of thousands of entities in Replicache, and index them via Orama. We're able to perform full-text search in single-digit ms. We persist the Orama index as JSON, so computation only happens once per mutation.

▲

jitl 4 days ago | parent | prev | next [-]

But, does Replicache work for your native targets? Or you are okay with a different data layer for native (sqlite) vs web (boutique data model on top of IndexedDB). At the start of the article it sounds like the goal is to use the same abstraction across web and mobile native and solutions that bifurcate implementation are unacceptable, but then we end up preferring a solution that's different between web target and native targets.

Zero (and I believe Replicache as well) layer their own SQL-like semantics on top of an arbitrary KV store, much like the layering of SQLite-over-IndexedDB discussed; like SQLite-over-IndexedDB, I believe they are storing binary byte pages in the underlying KV store and each page contains data for one-or-more Replicache/Zero records. The big difference between SQLite-over-IndexedDB and Zero-over-IndexedDB is that Zero is written with sympathy to IndexedDB's performance characteristics, whereas SQLite is written with sympathy to conventional filesystem performance.

On the subject of "keep whole thing in memory", this is what Zero does for its instant performance, and why they suggest limiting your working set / data desired at app boot to ~40MB, although I can't find a reference for this. Zero is smart though and will pick the 40MB for you though. Hopefully Zero folks come by and corrects me if I'm wrong.

▲

aboodman 4 days ago | parent | next [-]

Hi replicache/zero guy here

> Zero (and I believe Replicache as well) layer their own SQL-like semantics on top of an arbitrary KV store, much like the layering of SQLite-over-IndexedDB discussed

Replicache exposes only a kv interface. Zero does expose a SQL-like interface.

> I believe they are storing binary byte pages in the underlying KV store and each page contains data for one-or-more Replicache/Zero records.

The pages are JSON values not binary encoded, but that's an impl detail. At a big picture, you're right that both Replicache and Zero aggregate many values into pages that are stored in IDB (or SQLite in React Native).

> On the subject of "keep whole thing in memory", this is what Zero does for its instant performance, and why they suggest limiting your working set / data desired at app boot to ~40MB, although I can't find a reference for this. Zero is smart though and will pick the 40MB for you though. Hopefully Zero folks come by and corrects me if I'm wrong.

Replicache and Zero are a bit different here. Replicache keeps only up to 64MB in memory. It uses an LRU cache to manage this. The rest is paged in and out of IDB.

This ended up being a really big perf cliff because bigger applications would thrash against this limit.

In Zero, we just keep the entire client datastore in memory. Basically we use IDB/SQLite as a backup/restore target. We don't page in and out of it.

This might sound worse, but the difference is Zero's query-driven sync. Queries automatically fallback to the server and sync. So the whole model is different. You don't sync everything, you just sync what you need. From some upcoming docs:

https://i.imgur.com/y91qFrx.png

▲

local_surfer 4 days ago | parent | next [-]

I really like Zero’s approach: it feels very much like Triplit, including many of its features like query-based smart caching. However, what holds me back from using it is that, unlike Triplit, Zero currently lacks support for offline modifications, which must be a major obstacle for a truly local‑first library.

▲

aboodman 4 days ago | parent [-]

Zero isn't trying to be 'truly local-first'.

We're leveraging sync to make high-quality online software. We may come back to offline in the future, but it's not the priority today.

You can read more about our approach to offline here:

https://zero.rocicorp.dev/docs/offline

▲

mentalgear 2 days ago | parent [-]

strange then that is always mentioned as one of the most prominent local-first engines.

	▲	aboodman 2 days ago \| parent [-]
		The terminology in this area is still in flux, but for past year or so I've been trying to draw a distinction: https://i.imgur.com/B5iOd9y.png https://x.com/search?q=aboodman%20local-first%20zero&src=typ...

▲

jitl 4 days ago | parent | prev [-]

Notion screenshot ;)

	▲	aboodman 4 days ago \| parent [-]
		Big fan!

▲

isaachinman 4 days ago | parent | prev [-]

Yes, Replicache works beautifully on our mobile/native targets.

The constructor allows you to pass in any arbitrary KVStore provider, and we happen to use op-sqlite as its performance is exceptional.

There is no "different data layer" per se, just a different storage mechanism.

Replicache also holds a mem cache that is limited to ~50MB if I recall. Our use case is extremely data-heavy, so we might end up never migrating to Zero – who knows.

Perhaps I misunderstood your question, let me know if I can clarify further.

▲

jitl 4 days ago | parent [-]

Ah, I understood "native application in some targets" to mean you're writing application code in languages other than JavaScript/TypeScript; not that sometimes you're React Native and sometimes you're Web/DOM but you're always TypeScript.

Notion always* has a webview component, even in native apps, but we also have a substantial amount of "true native" Swift/Kotlin. We can't use Replicache/Zero today because our native code and our webview share the SQLite database and both need to be able to read and write the data there; if we use Replicache that would make our persisted data opaque bytes to Swift/Kotlin.

*There's many screens of the Android/iOS app that are entirely native but the editor will probably remain a webview for a while yet.

	▲	isaachinman 4 days ago \| parent [-]
		Yeah that makes sense for your use case. We're RN for web, mobile, and desktop, so it works smoothly for us.

▲

canadiantim 4 days ago | parent | prev [-]

What about relying on OPFS instead of Indexedb?