Right, but how do you scale that out on the server-side while protecting data on a per-user basis? Sorry if I'm missing something obvious.

Usually you create a separate database for every user.

This sounds _nuts_ from a traditional database mindset, but works great in Couch.

You can then create another database that replicates from all the user databases in order to perform your aggregate queries on the back end.

Seconded. This is the standard CouchDB approach: one database per user.

Sounds weird coming from my Postgres and MySQL background, but works great in practice, depending on your use case and if you clear out old revisions and unused docs, which for our use case can number into the thousands fairly rapidly.

> You can then create another database that replicates from all the user databases in order to perform your aggregate queries on the back end.

That sounds horribly space inefficent.

Yep.

Everything in software is a trade-off. This trades space efficiency for multi master replication with first class offline app experiences.

For many cases, that's a fine trade. Disks are cheap. If that isn't a fine trade for a particularly large dataset, use a different technology that's better at space efficiency and worse at other stuff.

I let the user decide to logout and destroy or just logout if it's a trusted device but obviously the local db could be accessed. Most users don't logout and I set a long cookie expiration.

You could also encrypt data.