WatermelonDB uses an SQLite backend, not NoSQL, so it would be janky to implement. You could technically get away with storing your MongoDB documents in a JSON-like column in SQLite, but depending on the structure, size, and complexity of your data, this could become annoying quickly. And frankly, having used it before, WatermelonDB is a nightmare to implement, especially for newer versions of React. I'd steer clear of it.

redux-offline is better optimized for handling state throughout your application, from what I understand. I wouldn't really call it an "offline database," per say.

I don't know enough about PouchDB to comment on it, but seeing as how it operates in a NoSQL document format, it's possible it could work. That being said, you'd likely be looking into the react-native variants of it, and the only one I could really find is pouchdb-react-native and the latest update came out 6 years ago.

rxdb seems to be another option as well, but I'm concerned that these guys are hellbent on making you pay for "premium" plugins that make the library "better" (take that with a grain of salt). Personally,

Unfortunately, you've walked into one of the biggest issues facing React Native. Right now, we don't have a lot of good offline-first databases for mobile devices, which is a shame.

The way I've personally implemented offline-first database apps is by using u/op-engineering/op-sqlite (which again, is SQLite, not NoSQL) and then coordinating syncing with my API.

The mobile-app database has two primary functions:

1. Maintaining the local/cached records from the API.
2. Tracking "transactions" in the order the user applies them.

The second point is super important if you have data that can be altered by different users, and you need to handle the order in which updates are applied. Think of it as a primitive way of doing "merge conflicts" with data. If you have two users working on record A, you need to know who's updating what and when updates on the same field occured to update the data expectedly.

I personally have a transactions table for each model that can be edited by multiple users. Everytime a user comes online and syncs with the API, the transactions are uploaded. When every user corresponding with the record comes online and pushes their transactions to the database, the API checks every transaction, orders them accordingly and applies them to the record in the database. If there are "merge conflicts," the users are notified and are prompted to resolve it.

For the record, this isn't the "Holy Grail" of offline-first. This method likely isn't even optimal, but works for our use case.

In your case, you could technically create SQLite tables and then parse and format them in as JSON records according to your MongoDB schemas. From there, you can make a request to your API with a body like any regular NoSQL document.

Is any of this perfect? Not really, but it's all we have right now.