Yes, CouchDB sounds very good for this - its simple protocol makes it very suitable for web applications [even offline, see pouchdb ] and mobile / desktop applications [again even offline, see Couchbase Mobile .
Unfortunately, I don’t know because of the large publicly available example of the code level, but the main idea is to use a combination of filtered replication and document validation:
The basic idea is that for your server-side copy of the user database, you have validation features configured to require the required document schemas and access control. The end user receives a replica of this database, which can be used for low latency and offline access - theoretically they can undermine their copy, but if the replication function is replicated, it will prevent damage to the database on the server side.
You can even set up a base database that is not publicly available, then use filtered replication to synchronize each user’s data with the server, side databases for each user — useful for centralized messaging, aggregate statistics that only need to back up one database and etc.
There are several high-level examples in this “New Features in Replication” article , especially “DesktopCouch” and “Need-to-know-based Data Sharing” to use snippets to the end.
UPDATE (2015/03/10) . I no longer recommend using CatchDB filtered replication as described above. There are several performance and scalability issues (if this is not about reliability) that arise when you try to replicate more than a few filtered channels from a central database. You can try Couchbase and Sync Gateway if you need read permissions at the document level or create your own changes for each user (for example, protected by special middleware) using _local_seq .