Offline-First Landscape – 2025

Summary

IntroductionWhen we set out to build Marco, we knew we were committing to two very difficult requirements: (1) IMAP-based, not API-based, and (2) cross-platform – web, Mac, Windows, Android, iOS.We had a handful of additional ancillary requirements. One of these was offline-first, and I can now say confidently that we drastically underestimated its complexity.I mentioned in a previous blog post that Missive was my daily driver in the recent past. It lacks offline support though, and this is one of the major downfalls of the product.At Marco we believe that full offline support is crucial. "Managing your emails on an airplane with no wifi" is an example use case we frequently come back to. You should be able to read, delete, respond, and organise your emails with no internet connection. When you land and connect to wifi, everything should seamlessly sync.That said, Marco is not a simple todo app. Marco is not an application that starts with zero data and grows in size gradually, as is the case with user-generated content like Notion, etc.Marco is an application that deals with hundreds of MB of data, and hundreds of thousands (or millions) of rows/entities.Essentially this means we are instantly jumping into the top 1% of heavy-duty use cases for offline-first implementations. Over time we realised that this actually rules out almost all available offline-first options.Starting Point: WatermelonDBI spent about a week deeply investigating the offline-first options available to us, in August 2024.We (perhaps naively) had committed to the idea that our offline-first architecture should be database-agnostic – the offline-first logic should "end" at the API layer. We did not want to manage sync tables or schemas in Postgres – we wanted to write API endpoints, and manage our database ourselves.Here's a rundown of the initial offline-first options we looked at:WatermelonDBFOSS, self-hostedDatabase agnosticBeen around for ages, used in many production applicationsPowerSyncNo...