Offline-First Landscape – 2025
marcoapp.io
marcoapp.io
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.
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.
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.
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.
> 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:
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://i.imgur.com/B5iOd9y.png
https://x.com/search?q=aboodman%20local-first%20zero&src=typ...
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).
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.
I’m glad this post made its way to HN, since it allowed me to reflect on how much progress we’ve made since it was written. The blog post doesn’t support comments, so here goes:
> The DX is the worst by quite a margin.
DX is something that we care a lot about. Like it’s a topic in every single planning and strategy session. We’ve made a ton of progress since this was posted, and we have a lot more on this front on our roadmap.
> Not only does it require Postgres-level integration
If you’re looking to stream data from your Postgres database to clients, I’m not aware of any other way to do this but to integrate with Postgres. So I’m not sure why this is framed in a negative light. PowerSync also only requires a user with SELECT privileges, so it’s not an invasive integration.
> it also needs a HA MongoDB cluster
It’s now possible to use Postgres for intermediary storage instead of MongoDB. I actually recall we gave you a shout out in one of our product updates on this :)
> a lot of arcane yaml configuration
We’ve since published a schema for the yaml config - add this to powersync.yaml:
# yaml-language-server: $schema=https://unpkg.com/@powersync/service-schema@latest/json-sche...
> It also required us to completely denormalise our Postgres tables, as relations are not properly supported across the sync buckets.
This is ultimately a function of our decision to build a system that scales well. Having said that, we have plans to address this limitation this year.
> we found horrifying problems like off-by-one bugs in their Drizzle ORM integration
This was fixed around the time of the post, and our Drizzle integration is now in beta i.e. fully supported in production environments.
> queries returning data from local db very slowly (100ms+),
It’s hard to say what was causing this without knowing more, but as mentioned elsewhere in the comments here we’ve since added support for OPFS which provides a big performance boost.
> and long initialisation times (45s+ after login to Marco) with the UI view not updating until the sync fully completed.
We’ve added APIs to solve this - if you want to sync everything up front you can use sync priorities to log the user in quickly and sync the rest in the background [1]. We’ve also implemented many optimizations like transport-level compression, a waaaay faster rust sync client, etc with more to come. Also, using sync streams (available in the next few weeks) [2] you can sync data just in time as the user navigates around the app instead of syncing everything up front.
> No real case studies
It’s often quite a slow process to get case studies published with large companies, but you can see logos of customers using PowerSync on our website. But yes.
[1] https://docs.powersync.com/usage/use-case-examples/prioritiz... [2] https://github.com/powersync-ja/powersync-service/discussion...
"The root cause is that all of these offline-first tools for web are essentially hacks. PowerSync itself is WASM SQLite... On top of IndexedDB."
But there's a new web storage API in town, Origin Private File System. https://developer.mozilla.org/en-US/docs/Web/API/File_System... "It provides access to a special kind of file that is highly optimized for performance and offers in-place write access to its content."
OPFS reached Baseline "Newly Available" in March 2023; it will be "Widely Available" in September.
WASM sqlite on OPFS is, finally, not a hack, and is pretty much exactly what the author needed in the first place.
The Rocicorp team have decided to focus on a different product, Zero, which is far less "offline-first" in that it does not sync all data, but rather syncs data based on queries. This works well for applications that have unbounded amounts of data (ie something like Instagram), but is _not_ what we want or need at Marco.
But notably, not directly atop. We build our own KV store that uses IDB just as block storage. So I sort of agree w/ you.
But if we were to build atop OPFS we'd also just be using it for block storage. So I'm not sure it's a win? It will be interesting to explore.
The majority of the cost in a database is often serializing/deserializing data. By using IDB from JS, we delegate that to the browser's highly optimized native code. The data goes from JS vals to binary serialization in one hop.
If we were to use OPFS, we would instead have to do that marshaling ourselves in JS. JS is much slower that native code, so the resulting impl would probably be a lot slower.
We could attempt to move that code into Rust/C++ via WASM, but then we have a different problem: we have to marshal between JS types and native types first, before writing to OPFS. So there are now two hops: JS -> C++ -> OPFS.
We have actually explored this in a previous version of Replicache and it was much slower. The marshalling btwn JS and WASM killed it. That's why Replicache has the design it does.
I don't personally think we can do this well until WASM and JS can share objects directly, without copies.
As mentioned, everything fast(ish) is using SQLite under the hood. If you don’t already know, SQLite has a limited set of types, and some funky defaults. How are you going to take this loosey-goosey typed data and store it in a backend database when you sync? What about foreign key constraints, etc., can you live without those? Some of the sync solutions don’t support enforcing them on the client.
Also, the SQLite query planner isn’t great in my experience, even when you’re only joining on ids/indexes.
Document databases seem more friendly/natural, but as mentioned indexeddb is slow.
I wish this looked at https://rxdb.info/ more. They have some posts that lead me to believe they have a good grasp on the issues in this space at least
Also, OPFS is a newish thing everyone is using to store SQLite directly instead of wrapping IndexedDB for better performance.
Notion is a very async collaborative application and we rely on a form of transactions. When you make a change in Notion like moving a bunch of blocks from one page to another, we compose the transaction client-side given the client's in-memory snapshot view of the universe, and send the transaction to the server. If the transaction turns out to violate some server-side validation (like a permissions issue), we reject the change as a unit and roll back the client.
I'm not sure how we'd do this kind of thing with RxDb. If we model it as a delete in one document and an insert into another document, we'd get data loss. Maybe they'd tell us our app shouldn't have that feature.
You could always ask your question in their discord - I've always gotten prompt and helpful responses
It has so many optimizations and features that the others dont. And is even better when you use the premium addons. I compared it to pretty much everything, and its not even close.
It would be nice to have WebSQL though, even if it has to be spec'd as "it's sqlite".
WebSQL was a clunky API, but not as clunky as IndexedDB which is truly yucky and very easy to get wrong in modern apps that use promises.
It's much better than WebSQL could ever be. You get the full power of modern SQLite, with the version, compile options, additional extensions, all under your control.
Since the post is already a few months old, it's worth mentioning that the newly released Triplit 1.0 had had a massive performance update (up to 10x). You should definitely reconsider it for larger scale data projects and the team is really highly knowledgable. https://www.triplit.dev/blog/triplit-1.0
There’s just an assumption that these client databases don’t need mature tools and migration strategies as “it’s just a web client, you can always just re-sync with a server”. Few client db felt mature enough to warrant building my entire app on as they’re not the easiet to migrate off of.
I also tried LokiJS which is mentioned in the OP. I even forked (renamed it SylvieJS lol) it to rewrite it in TS and update some of the adapters. I ultimately moved away from it as well. I found an in memory db will struggle past a few hundred mbs which I hit pretty quickly.
No matter what db you use, you’re realistically using indexed db behind the hood. What surprised me was that a query to indexed db can be slower than a network call. Like what.
Initially I built only a desktop client, because I didn't like IndexedDB. After the app got into HN, someone recommended to check for OPFS (Origin Private File System).
Now we have a full offline-first app in web using SQLite on top of OPFS. We didn't test it with large scale yet, but so far looks very promising. The good thing is that we use Kysely as an abstraction for performing queries in SQLite which helps us share most of the code across both platforms (electron + web) with some minor abstractions.
You can check the implementation in Github: https://github.com/colanode/colanode
It's oriented around event sourcing and syncs the events, which get materialized into local table views on clients. It's got pretty slick devtools too.
p.s Just wanted to say thank you for all the contribution you do here on HN. Colanode (the app I'm building) is an alternative to Notion and I learned a lot about how you (Notion) build things through reading your comments.
* We added some serious typescript types
* We have sorting and ordering on fields
* We added the $like operator
* We added reactive queries on the backend
We're on a mission to make the best DX possible for building apps. We take your feedback seriously, and ship as quick as we can.
As the author mentions in the comments here:
> InstantDB has matured massively and is definitely worth a look for anyone starting a new project.
If you get a chance to try us out, we'd love feedback :)
Everything you see on instantdb.com is open source, and hosted in one monorepo here: https://github.com/instantdb/instant
I wrap that in FlatDB, which is an opinionated flat cache for the files with metadata inline, used for very fast searches (searching 150k messages in less than 20ms on my 4 year old phone). This handles a lot of tricky cases, like accidental cache modification, and editing the database in different tabs.
There's even a sync algorithm that synchronizes notes across devices. https://github.com/kasrasadeghi/pipeline-js/blob/main/assets...
This is discussed in the blog post. A lot of offline-first tools fall apart at this scale.
Iirc there are different limits on IndexedDB sizes depending on the browser/platform, and the tighter limit is around 1GB. But I would love to hear from people that ran into those limits.
Except in pre-sales, I can’t imagine anyone using an email heavy workflow in 2025.
In my personal life, email is only for one way transactions. Where some company is sending email to me or spam. Even the one newsletter I subscribe to - Stratechery is available as a podcast and an RSS feed.
In my professional life, of course all internal communication happens on Slack (700 employees) and even in consulting, the first thing we do after a deal closes is either invite customers to our Slack or ask to be invited to their platform.
This is a solution in search of a problem.
Turns out a lot of other people do too.
There's been a massive influx of "new gen" email clients in the past year or so.
That said, we're not an "AI product".
The selling point is that it's IMAP primitive, as the blog post mentions.
Thunderbird is nice, but it's not cross-platform. Superhuman and Notion Mail are nice, but they only support Google and Outlook.
Apple Mail is truly awful.
There's a gap in the market, and as I said we're building it for ourselves.
It’s the first thing you do if you are trying to make a product that you plan to monetize is ask - who is the ideal user and how will we market it. If it’s just a hobby project to learn a new to you technology, that’s fine or if you just wanted to scratch an itch.
What do you mean by this? I send 5-15 emails a day at a minimum throughout the day and receive just as many directly with another 2-3x as cc in various distribution lists (which I read in full). Add in server notifications, automated reports from data processing scripts, and the generic info@company.com inbox and it's probably close to 100 in a day with ease. Lots of skimming and Ctrl-Q'ing and it's hardly a burden.
The lasting power of email is that it's one of the few federated communication channels that has a global network effect. Email and chat are two different media for different purposes. You have plausible deniability when a single message in a group chat is missed. When an email is sent to the team with a change in procedure you can have some expectations that it will be seen and it also provides a one-one or one-many channel for clarification.
I'm not familiar with how the sales world works but I use email every day with clients, vendors, the team, my boss(es), and many other intra-company relationships. I think you have a lack of imagination in this regard :)
And all of those can just as easily be sent to a Slack channel without everyone bothering to create email rules since they are automatically sent to the correct Slack channel where if it’s an actionable alert, a responsible party can add an “ack” reaction that kicks off a workflow that says this person is handling it.
This can also be integrated into your CRM or wherever you call something like ServiceNow. We have all sorts of workflows and integrations with Slack.
> You have plausible deniability when a single message in a group chat is missed. When an email is sent to the team with a change in procedure you can have some expectations that it will be seen and it also provides a one-one or one-many channel for clarification
How are you any less likely to miss an email than miss a channel set aside for leadership announcements that only certain people can send a message too? Then you also have the “reply all” issue that I’ve seen blow up email servers. Messages allow threading etc in Slack and it’s a lot easier to ignore a thread that doesn’t pertain to you and follow those that do.
Everyone at our 1000 person company communicates through Slack up to an including our CEO for announcements and updates.
I don’t think I’ve emailed someone internally in over 8 years except to forward an external email and during that time, I’ve worked for startups and the second largest employer in the US.
In my world... EVERYONE (50/50 internal and external) is on email and/or Teams (or the phone). It works. Shit gets done. It's a small, high-trust environment of autonomous people doing rapidly changing work.
There is a working world where email makes sense and trying to "make Slack a thing" would be (rightfully) scoffed at. If I'm yanked out of this and dropped into some Slack/ticket/KPI/whatever environment I will adapt and play ball.
There are times where I’m running errands during the day or traveling and working late and I schedule a message for 8:00 or 9:00 their time.
The issue isn't people being in a different timezone in a one-to-one setup (that's easy to do), and if direct answers from a group are needed then it's not too different, but having any kind of sensible asynchronous discussion on slack is basically impossible (having suffered through far too many). Email (and to a lesser extent forums) are far better for this.
In my experience, email seems common for customer support.
Now I’m seeing more companies that want to integrate with messaging platforms for customer support - one of my specialties is implementing call centers with Amazon Connect. I’ve never been asked in 5 years to integrate customer support with inbound email.
The performance has been pretty decent, even with multi-gigabyte mailboxes.
Do you not have any need for CRDT?
And by the way, we didn't opt for an in-house IndexedDB solution because we have targets in which IndexedDB does not exist (mobile, desktop).
How do you handle offline-first in your mobile apps? Are your mobile apps webviews?
On mobile and desktop, IndexedDB does not exist, and SQLite is available first-class.
P.S. I am the author
In a local-first approach, changes are initially stored locally, but there's an expectation to eventually connect to a server backend to merge these changes, typically within days, weeks, or months. On the other hand, an offline-first approach may not even require a backend, functioning seamlessly regardless of internet connectivity.
These distinctions may blur as sync engines improve, allowing clients to remain offline for increasingly extended periods. Ultimately, the differentiating factor might hinge on whether there's a central authority that enforces migrations or changes.