Replicated data size is much larger on the device compared to what is on the server

Have you compacted the local database?

CouchDB is an append-only file format, so updating a document makes the tree grow as much as inserting a new one. Even inserting a new node adds more space than strictly necessary because the updated intermediate b-tree nodes get appended instead of overwritten. The space is reclaimed when the database is compacted.

So if you've been incrementally replicating from the upstream database, the local db will be larger. Compacting should take care of that.

--Jens

Thanks for the quick reply, Jens!
Yes - I compact the local database. I am aware that saving a document adds a new version. Compacting the local DB actual increased the size temporary then it went back to where it was but it did not become smaller.I am starting to think that replication alone is not the main cause for the issue. When I create a new user with its own empty database and start creating documents on the device - the local database is still nearly 3 to 4 times larger than what is replicated to the server. I still believe that this is a Couchbase mobile issue. Since my app is a couchapp(I am using Phongeap to make it "native" ) I can test in a browser on a computer running Couchbase Server -- the data size is very close to the remote database size in this case. I also checked the views and didn't find anything alarming (best practices used).

How are you measuring database sizes, locally and remotely?

I'm not sure where a disparity in size would come from, as Couchbase Mobile is, literally, CouchDB. It's a little bit forked from 1.1 but not in any significant way.

On the iOS device I am looking at the usage under Settings> General > Usage - before and after the replication takes place and / or before and after I create a new empty database and add documents to it.
On the remote database I am looking at Futon's overview page (each user has separate database on the server).

You can't really compare your app's total disk usage against just the size of the remote databases; it ignore anything else your app is storing locally, like caches.

Take a look at the .couch files in Library/Application Support/CouchbaseMobile/ and see if they correspond to the sizes you expect. If they do, look around the rest of the app data files to see what's using up space. (On the simulator you can look at the app's files directly since they're just in a directory buried in your OS X home directory; on a device you'll need an app like iExplorer.)

Thanks for the tip! Looking at the simulator files the file sizes actually do match - this is a great news. I don't see what else is contributing to the disk space usage reported by iOS. I will try this on an actual device - clearly not a Couch DB issue.

Whew! My first guess would be caching by PhoneGap; those files are likely in Library/Caches. Or just run 'du' on the whole directory tree, or use a tool like OmniDiskSweeper that shows you what files are taking up the most disk space.

Thanks! I see the large files. Looks like the views are too large after all. It would probably make sense to clear those views when the user logs out.

Yeah, I don't think Futon includes view sizes when reporting the size of a database.

If the views are larger than you'd like, make sure you're not putting too much in them. I've found that often people emit the entire document as the value; this isn't necessary because you can get basically the same effect by querying with the include_docs flag. (It's slightly faster if the document is embedded in the view, though; this is one of those time-space tradeoffs.)

Thanks for the advice! While the views in my app are not emitting documents some of them of them emit large number of fields. I will try to optimize that.