6 ms·

Offline-First Landscape – 2025

125 points by Onavo 1y ago

isaachinman 1y ago
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.
- jitl 1y ago
  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.
  - isaachinman 1y ago
    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 1y ago
      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 1y ago
        Yeah that makes sense for your use case. We're RN for web, mobile, and desktop, so it works smoothly for us.
  - aboodman 1y ago
    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 https://i.imgur.com/y91qFrx.png
    - jitl 1y ago
      Notion screenshot ;)
      - aboodman 1y ago
        Big fan!
    - local_surfer 1y ago
      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.
- local_surfer 1y ago
  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 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 1y ago
    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.
- canadiantim 1y ago
  What about relying on OPFS instead of Indexedb?
- kobieps 1y ago
  (I’m on the PowerSync team) 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-schema/powersync-config.json 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/prioritized-sync https://docs.powersync.com/usage/use-case-examples/prioritiz... [2] https://github.com/powersync-ja/powersync-service/discussions/347 https://github.com/powersync-ja/powersync-service/discussion...
- swyx 1y ago
  could i please try out the product? i'm the target audience.
fmajid 1y ago
The OP does not mention that IndexedDB itself is built on top of... SQLite. Abandoning WebSQL was truly a heinous crime against the Web.
- dunham 1y ago
  It's leveldb with a custom key format in chrome and electron. It would be nice to have WebSQL though, even if it has to be spec'd as "it's sqlite".
- jitl 1y ago
  IndexedDB is a standard and can be implemented however the user-agent sees fit. Chromium source tree has an implementation on LevelDB and an implementation on SQLite; I'm not sure how they pick the appropriate backend. Firefox and WebKit both appear to use SQLite as the backend. 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.
  - nchmy 1y ago
    I think chromium still uses leveldb, but have been working towards changing to sqlite for a while. https://issues.chromium.org/issues/40253999 https://issues.chromium.org/issues/40253999
- matharmin 1y ago
  wa-sqlite on top of OPFS is actually pretty great these days. Performance is about half of what I'd get in native SQLite, which is not too bad overall. It's around 10x faster than SQLite on top of IndexedDB for large databases in my experience. 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.
rudedogg 1y ago
I’m doing offline-first apps at work and want to emphasize that you’re constraining yourself a lot trying to do this. 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/ 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.
- jitl 1y ago
  I've been a bit put off by rxdb's lack of transactions (see https://rxdb.info/transactions-conflicts-revisions.html https://rxdb.info/transactions-conflicts-revisions.html) and the sometimes self-congratulatory tone in their docs. 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.
  - nchmy 1y ago
    Yeah, their tone can be a bit weird sometimes, but its by far the best browser db that I've found. You could always ask your question in their discord - I've always gotten prompt and helpful responses
- nchmy 1y ago
cfu28 1y ago
I struggled with this landscape a few years ago when building Mere Medical to manage my own medical records. To be fair, I was aiming for not just offline-first, but offline-only (user data was exclusively stored on device, not in any server). I got surprisingly far with RxDB, but it definitely felt like I was pushing these tools and the web platform to their limit. 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.
- jitl 1y ago
  On midrange and below Android devices, literally any local persisted data access can be slower than a network call. Even a point read from a small SQLite b-tree can be coming off a $3 microsd card and a CPU equivalent to a 10 year old iPhone. https://infrequently.org/2024/01/performance-inequality-gap-2024/ https://infrequently.org/2024/01/performance-inequality-gap-...
dfabulich 1y ago
The punchline of this article is that all the implementations they tried (WatermelonDB, PowerSync, ElectricSQL, Triplit, InstantDB, Convex) are all built on top of IndexedDB. "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_API/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.
- jitl 1y ago
  We do see about 10x the database row corruption rate w/ WASM OPFS SQLite compared to the same logic running against native SQLite. For read-side cache use-case this is recoverable and relatively benign but we're not moving write-side use-case from IndexedDB to WASM-OPFS-SQLite until things look a bit better. Not to put the blame on SQLite here, there's shared responsibility for the corruption between the host application (eg Notion), the SQLite OPFS VFS authors, the user-agent authors, and the user's device to ensure proper locking and file semantics.
- isaachinman 1y ago
  Yeah, I did fail to mention OPFS in the blog post. It does look very promising, but we're not in a position to build on emergent tech – we need a battle-tested stack. Boring over exciting.
  - culi 1y ago
    Not sure anything in the offline-first ecosystem qualifies as "boring" yet. You would need some high-profile successful examples that have been around for a few years to earn that title
    - 1y ago
hakanshehu 1y ago
Nice post! I'm building an offline-first collaboration app and went on the route of building a custom sync engine, mainly because the app is open-source and I didn't want to introduce any dependency. I've implemented a simple cursor based sync with Postgres on server and SQLite in client side. 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 https://github.com/colanode/colanode
- jitl 1y ago
  Depending on your data model, LiveStore is a completely open-source, SQLite based approach for local first sync-y apps: https://livestore.dev/ https://livestore.dev/ 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.
  - hakanshehu 1y ago
    I did look into it back then, but was not very convenient for my use case. Apart from the data model, I wanted to use Yjs for conflict resolution and wanted more direct control over the sync. 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.
victorbjorklund 1y ago
Related question to people building local-first - what size of db is too big? I always see examples doing todo lists etc which seems perfect for this. But what about apps with larger databases. When does local-first no longer make sense?
- isaachinman 1y ago
  Our dbs range from hundreds of MB to gigabytes. This is discussed in the blog post. A lot of offline-first tools fall apart at this scale.
- wonger_ 1y ago
  I wonder the same thing, especially thinking about local-first image storage. 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.
  - isaachinman 1y ago
    It really depends on the browser. There's a good breakdown here: https://rxdb.info/articles/indexeddb-max-storage-limit.html https://rxdb.info/articles/indexeddb-max-storage-limit.html
- local_surfer 1y ago
  Maybe duckdb-wasm is the answer (also check sqlRooms github)
scarface_74 1y ago
Email though? 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.
- isaachinman 1y ago
  Actually, the complete opposite. We're building this app because we need it ourselves. Turns out a lot of other people do too.
  - scarface_74 1y ago
    What’s the sales pitch for using email in 2025 for communication aside from sales?
    - isaachinman 1y ago
      No sales pitch at all. USPs are on our homepage. If it doesn't appeal to you I get it. Different people have different needs. 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".
      - scarface_74 1y ago
        [flagged]
        jamiek88 1y ago
        [flagged]
nmjenkins 1y ago
Or you could … just build it directly on indexedDB. That's what we did for our offline support at Fastmail, with just a small wrapper function to make the API promise based: https://www.fastmail.com/blog/offline-architecture/ https://www.fastmail.com/blog/offline-architecture/ The performance has been pretty decent, even with multi-gigabyte mailboxes.
- isaachinman 1y ago
  Saw that Fastmail released offline support recently, nice work! Do you not have any need for CRDT?
  - nmjenkins 1y ago
    No, CRDTs wouldn’t be useful right for what we currently do. If we ever wanted collaborative text editing for something then we’d use them for sure.
    - isaachinman 1y ago
      Fair enough, not needing CRDTs makes life a lot easier! 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?
- idle_zealot 1y ago
  The offline support has been great. I used to have to keep another mail app synced with my fastmail inbox over IMAP just in case I needed access to an email and had crappy connection. Now I can just have the one email icon on my homescreen.
stopachka 1y ago
Instant founder here. Since this blog post was written (Jan 11): * 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 :)
- local_surfer 1y ago
  I find InstantDB's page confusing: How far is it open-source and self-hostable ? I don't mind you having a sustainable cash flow, but it all seems a bit unclear which parts are fully open-source and self-hostable.
  - stopachka 1y ago
    > I don't mind you having a sustainable cash flow, but it all seems a bit unclear which parts are fully open-source and self-hostable. Everything you see on instantdb.com is open source, and hosted in one monorepo here: https://github.com/instantdb/instant https://github.com/instantdb/instant
MerrimanInd 1y ago
What's the overlap between the offline-first and local-first paradigms these days? Both technologically and philosophically?
- local_surfer 1y ago
  Not sure there is a formal definition, but here's my current understanding: 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.
kaz-inc 1y ago
I have a wrapper around IndexedDB I've been using since 2020ish for my offline-first texting based notes system called FileDB, which makes indexedDB look like a filesystem. https://github.com/kasrasadeghi/pipeline-js/blob/main/assets/filedb.js https://github.com/kasrasadeghi/pipeline-js/blob/main/assets... 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/sync.js#L90 https://github.com/kasrasadeghi/pipeline-js/blob/main/assets...
local_surfer 1y ago
Triplit and Orama are definitely often overlooked hidden gems. 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 https://www.triplit.dev/blog/triplit-1.0
Existenceblinks 1y ago
These topic and mentioned tools always fail to demonstrate how sync engine works in multiple players modes. And mostly only for backend written in TS/JS, worse it's only for using with 3rd service (which you couldn't put your business logic in here). The first thing i scan in these tools' docs are how they handle write conflict whose conflict is semantic level, not data exchange format level.
marcobambini 1y ago
There is a new solution that is worth considering: https://github.com/sqliteai/sqlite-sync https://github.com/sqliteai/sqlite-sync P.S. I am the author
wernst 1y ago
Triplit has migrated its data format away from triples since this post was authored, so the memory concerns mentioned are no longer relevant since 1.0 https://www.triplit.dev/blog/triplit-1.0 https://www.triplit.dev/blog/triplit-1.0 (source: i'm Triplit author). I don't think triples as a format are inherently bad but for us it did entail more data on disk, more difficult and slower querying, and more objects in the JS heap ballooning RAM.
- GermanJablo 1y ago
  Now you're storing all the rows as units, right? When users create tables in Triplit, do they end up with really different tables or are they more more like a single table of content in json + table_meta_ref? I would love to know more about architecture and the changes that you have made
wener 1y ago
So, the final choice is dexie + custom backend? I've researched these open source solution before, I think dexie is the choice that you will never regret. fyi https://dexie.org/ https://dexie.org/
- isaachinman 1y ago
  Sure, that works if you only operate in environments where IndexedDB is available. On mobile and desktop, IndexedDB does not exist, and SQLite is available first-class.

125 points by Onavo 1y ago

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.

jitl 1y ago
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.
- isaachinman 1y ago
  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 1y ago
    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 1y ago
      Yeah that makes sense for your use case. We're RN for web, mobile, and desktop, so it works smoothly for us.
- aboodman 1y ago
  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 https://i.imgur.com/y91qFrx.png
  - jitl 1y ago
    Notion screenshot ;)
    - aboodman 1y ago
      Big fan!
  - local_surfer 1y ago
    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.
local_surfer 1y ago
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 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 1y ago
  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.
canadiantim 1y ago
What about relying on OPFS instead of Indexedb?
kobieps 1y ago
(I’m on the PowerSync team) 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-schema/powersync-config.json 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/prioritized-sync https://docs.powersync.com/usage/use-case-examples/prioritiz... [2] https://github.com/powersync-ja/powersync-service/discussions/347 https://github.com/powersync-ja/powersync-service/discussion...
swyx 1y ago
could i please try out the product? i'm the target audience.

fmajid 1y ago

The OP does not mention that IndexedDB itself is built on top of... SQLite. Abandoning WebSQL was truly a heinous crime against the Web.

dunham 1y ago
It's leveldb with a custom key format in chrome and electron. It would be nice to have WebSQL though, even if it has to be spec'd as "it's sqlite".
jitl 1y ago
IndexedDB is a standard and can be implemented however the user-agent sees fit. Chromium source tree has an implementation on LevelDB and an implementation on SQLite; I'm not sure how they pick the appropriate backend. Firefox and WebKit both appear to use SQLite as the backend. 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.
- nchmy 1y ago
  I think chromium still uses leveldb, but have been working towards changing to sqlite for a while. https://issues.chromium.org/issues/40253999 https://issues.chromium.org/issues/40253999
matharmin 1y ago
wa-sqlite on top of OPFS is actually pretty great these days. Performance is about half of what I'd get in native SQLite, which is not too bad overall. It's around 10x faster than SQLite on top of IndexedDB for large databases in my experience. 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.

rudedogg 1y ago

I’m doing offline-first apps at work and want to emphasize that you’re constraining yourself a lot trying to do this. 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/ 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.

jitl 1y ago
I've been a bit put off by rxdb's lack of transactions (see https://rxdb.info/transactions-conflicts-revisions.html https://rxdb.info/transactions-conflicts-revisions.html) and the sometimes self-congratulatory tone in their docs. 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.
- nchmy 1y ago
  Yeah, their tone can be a bit weird sometimes, but its by far the best browser db that I've found. You could always ask your question in their discord - I've always gotten prompt and helpful responses
nchmy 1y ago

cfu28 1y ago

I struggled with this landscape a few years ago when building Mere Medical to manage my own medical records. To be fair, I was aiming for not just offline-first, but offline-only (user data was exclusively stored on device, not in any server). I got surprisingly far with RxDB, but it definitely felt like I was pushing these tools and the web platform to their limit. 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.

jitl 1y ago
On midrange and below Android devices, literally any local persisted data access can be slower than a network call. Even a point read from a small SQLite b-tree can be coming off a $3 microsd card and a CPU equivalent to a 10 year old iPhone. https://infrequently.org/2024/01/performance-inequality-gap-2024/ https://infrequently.org/2024/01/performance-inequality-gap-...

dfabulich 1y ago

The punchline of this article is that all the implementations they tried (WatermelonDB, PowerSync, ElectricSQL, Triplit, InstantDB, Convex) are all built on top of IndexedDB. "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_API/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.

jitl 1y ago
We do see about 10x the database row corruption rate w/ WASM OPFS SQLite compared to the same logic running against native SQLite. For read-side cache use-case this is recoverable and relatively benign but we're not moving write-side use-case from IndexedDB to WASM-OPFS-SQLite until things look a bit better. Not to put the blame on SQLite here, there's shared responsibility for the corruption between the host application (eg Notion), the SQLite OPFS VFS authors, the user-agent authors, and the user's device to ensure proper locking and file semantics.
isaachinman 1y ago
Yeah, I did fail to mention OPFS in the blog post. It does look very promising, but we're not in a position to build on emergent tech – we need a battle-tested stack. Boring over exciting.
- culi 1y ago
  Not sure anything in the offline-first ecosystem qualifies as "boring" yet. You would need some high-profile successful examples that have been around for a few years to earn that title
  - 1y ago

hakanshehu 1y ago

Nice post! I'm building an offline-first collaboration app and went on the route of building a custom sync engine, mainly because the app is open-source and I didn't want to introduce any dependency. I've implemented a simple cursor based sync with Postgres on server and SQLite in client side. 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 https://github.com/colanode/colanode

jitl 1y ago
Depending on your data model, LiveStore is a completely open-source, SQLite based approach for local first sync-y apps: https://livestore.dev/ https://livestore.dev/ 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.
- hakanshehu 1y ago
  I did look into it back then, but was not very convenient for my use case. Apart from the data model, I wanted to use Yjs for conflict resolution and wanted more direct control over the sync. 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.

victorbjorklund 1y ago

Related question to people building local-first - what size of db is too big? I always see examples doing todo lists etc which seems perfect for this. But what about apps with larger databases. When does local-first no longer make sense?

isaachinman 1y ago
Our dbs range from hundreds of MB to gigabytes. This is discussed in the blog post. A lot of offline-first tools fall apart at this scale.
wonger_ 1y ago
I wonder the same thing, especially thinking about local-first image storage. 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.
- isaachinman 1y ago
  It really depends on the browser. There's a good breakdown here: https://rxdb.info/articles/indexeddb-max-storage-limit.html https://rxdb.info/articles/indexeddb-max-storage-limit.html
local_surfer 1y ago
Maybe duckdb-wasm is the answer (also check sqlRooms github)

scarface_74 1y ago

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

isaachinman 1y ago
Actually, the complete opposite. We're building this app because we need it ourselves. Turns out a lot of other people do too.
- scarface_74 1y ago
  What’s the sales pitch for using email in 2025 for communication aside from sales?
  - isaachinman 1y ago
    No sales pitch at all. USPs are on our homepage. If it doesn't appeal to you I get it. Different people have different needs. 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".
    - scarface_74 1y ago
      [flagged]
      - jamiek88 1y ago
        [flagged]

nmjenkins 1y ago

Or you could … just build it directly on indexedDB. That's what we did for our offline support at Fastmail, with just a small wrapper function to make the API promise based: https://www.fastmail.com/blog/offline-architecture/ https://www.fastmail.com/blog/offline-architecture/ The performance has been pretty decent, even with multi-gigabyte mailboxes.

isaachinman 1y ago
Saw that Fastmail released offline support recently, nice work! Do you not have any need for CRDT?
- nmjenkins 1y ago
  No, CRDTs wouldn’t be useful right for what we currently do. If we ever wanted collaborative text editing for something then we’d use them for sure.
  - isaachinman 1y ago
    Fair enough, not needing CRDTs makes life a lot easier! 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?
idle_zealot 1y ago
The offline support has been great. I used to have to keep another mail app synced with my fastmail inbox over IMAP just in case I needed access to an email and had crappy connection. Now I can just have the one email icon on my homescreen.

stopachka 1y ago

Instant founder here. Since this blog post was written (Jan 11): * 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 :)

local_surfer 1y ago
I find InstantDB's page confusing: How far is it open-source and self-hostable ? I don't mind you having a sustainable cash flow, but it all seems a bit unclear which parts are fully open-source and self-hostable.
- stopachka 1y ago
  > I don't mind you having a sustainable cash flow, but it all seems a bit unclear which parts are fully open-source and self-hostable. Everything you see on instantdb.com is open source, and hosted in one monorepo here: https://github.com/instantdb/instant https://github.com/instantdb/instant

MerrimanInd 1y ago

What's the overlap between the offline-first and local-first paradigms these days? Both technologically and philosophically?

local_surfer 1y ago
Not sure there is a formal definition, but here's my current understanding: 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.

kaz-inc 1y ago

I have a wrapper around IndexedDB I've been using since 2020ish for my offline-first texting based notes system called FileDB, which makes indexedDB look like a filesystem. https://github.com/kasrasadeghi/pipeline-js/blob/main/assets/filedb.js https://github.com/kasrasadeghi/pipeline-js/blob/main/assets... 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/sync.js#L90 https://github.com/kasrasadeghi/pipeline-js/blob/main/assets...

local_surfer 1y ago

Triplit and Orama are definitely often overlooked hidden gems. 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 https://www.triplit.dev/blog/triplit-1.0

Existenceblinks 1y ago

These topic and mentioned tools always fail to demonstrate how sync engine works in multiple players modes. And mostly only for backend written in TS/JS, worse it's only for using with 3rd service (which you couldn't put your business logic in here). The first thing i scan in these tools' docs are how they handle write conflict whose conflict is semantic level, not data exchange format level.

marcobambini 1y ago

There is a new solution that is worth considering: https://github.com/sqliteai/sqlite-sync https://github.com/sqliteai/sqlite-sync P.S. I am the author

wernst 1y ago

Triplit has migrated its data format away from triples since this post was authored, so the memory concerns mentioned are no longer relevant since 1.0 https://www.triplit.dev/blog/triplit-1.0 https://www.triplit.dev/blog/triplit-1.0 (source: i'm Triplit author). I don't think triples as a format are inherently bad but for us it did entail more data on disk, more difficult and slower querying, and more objects in the JS heap ballooning RAM.

GermanJablo 1y ago
Now you're storing all the rows as units, right? When users create tables in Triplit, do they end up with really different tables or are they more more like a single table of content in json + table_meta_ref? I would love to know more about architecture and the changes that you have made

wener 1y ago

So, the final choice is dexie + custom backend? I've researched these open source solution before, I think dexie is the choice that you will never regret. fyi https://dexie.org/ https://dexie.org/

isaachinman 1y ago
Sure, that works if you only operate in environments where IndexedDB is available. On mobile and desktop, IndexedDB does not exist, and SQLite is available first-class.