~10 years ago, CouchDB was the answer to this problem. I don't know what the status of that is in 2025, but at the time it was used to e.g. sync airplane sales tablets with a central database once they were back on the ground and online.
This space is very much alive and well and I'm really glad there's more competition cropping up from smaller projects like OP.
Disclaimer: I have worked on a sync backend for a company in this space for the last 8 years. You can probably find out where if you look, but this comment won't be a sales pitch.
Competition like this has incredible value for communities with poor internet access but reasonable development capabilities. Think about travelling doctors in the lesser developed countries and areas of Africa for instance. Quite often entire villages get medical checkups done, with data being recorded on a tablet. This can be synced once the doctor gets to a town with internet access for follow-up. Of course, projects like the above do not have big budgets. Unfortunately they are priced out of using a lot of tech to solve these problems (my company included in this statement)
On the more enterprise-y side, which is where I mostly sit, a lot of airlines, cruise ships, retail and field-based industry use these technologies, since they are prone to periods of being completely offline or in a P2P mesh only. Cloud databases or even regular replicated databases running in-situ are a non-starter, since there won't be anybody around to administer it. Replication is a difficult problem at the best of times, let alone in periods of comms downtime.
Not an expert on CouchDB, but used it recently in a project and loved the syncing with the corresponding pouchdb at the frontend. My main problem, what was missing imho was security: Interactions with couchdb where directly with the database, ie no intermediate API available. Maybe that was a good idea when couchDB was designed, but it made me feel uncomfortable in 2024. If anyone knows of an intermediate API-Layer for couchdb, please post.
Interesting that you're seeing the lack of intermediate server/API as a drawback. InstantDB sees it as progress, see their essay on it:
Yeah, what happened to CouchDB? I thought it would be much more popular, but I haven't heard of it in years. Maybe this problem isn't actually important, or maybe people don't know they can solve it in this way?