couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Klein <>
Subject Re: The state of filtered replication
Date Wed, 25 May 2016 11:25:46 GMT
2016-05-25 12:48 GMT+02:00 Stefan du Fresne <>:

> So to be clear, this is effectively replacing replication— where the
> client negotiates with the server for a collection of changes to download—
> with a daemon that builds up a collection of documents that each client
> should get (and also presumably delete), which clients can then query for
> when they’re able?

Sorry, didn't describe well enough.

On Serverside we have one big database containing all documents and one db
for each user.
The clients always replicate to and from their individual userdb,
unfiltered. So the db for a user is a 1:1 copy of their pouchdb/... on
their client.

Initially we set up a filtered replication for each user from servers main
database to the server copy of the users database.
With this we ran into performance problems and sooner or later we probably
would have ran into issues with open file descriptors.

So what we do instead is listening to the changes of the main database and
distribute the documents to the servers userdb, which then are synced with
the clients.

Note: this is only for documents the users actually work with (as in
possibly modify), for queries on the data we query views on the main

For the way back, we listen to the _dbchanges, so we get an event for
changes on the users dbs, get that change from the users db and determine
what to do with it.
We do not replicate back users changes to the main database but rather have
an internal API to evaluate all kinds of constrains on users input.
If you do not have to check users input, you could certainly listen to
_dbchanges and "blindly" one-shot replicate from the changed DB to your
main DB.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message