But if you want to build an app with its own real functionality that has sync added (like a TODO list that syncs with other devices) and is entirely offline-first where you can go weeks without a connection, you better keep searching. Maybe have a look at PouchDB.
I'm interested in solutions that allow a traditional relational db instead of a key-value store. Seems like with indexeddb on the client, and postgres on the server, you could probably keep a segment synced.
> The one thing I dislike about couchdb is the default "user-per-db" model.
Why exactly? I think the overhead of the DBs is rather small. It's not like having a MySQL DB for every user ;)
Also, you can achieve something like "global data" as well: Either replicate from users' DBs to a shared DB or maybe make some kind of "system" user that has access to the users' DBs. I'm not an expert, but that's what I figured out so far with my limited experience.
Let's say you are making a CRM with couch/pouch. Let's say that you have permissions to see a Customer record, but it is shared across your company. How do you sync that? It's not owned by a user, it's owned by the company. What happens if permissions change?
Regarding the "get a connection within one hour", that's only for automated, scheduled retries. When your app becomes online or is started up, no matter after how many hours or days have elapsed, we do continue retrying the messages unless you have a discard policy in place to remove them. The limited retry policy is related to not banging on a backend that is down or unreachable, etc.