I think the real downsides are scaling and performance but there are options at least. Given that TouchDB is essentially couchdb mapped onto sqlite I do wonder if there are going to be good options to map couchdb replication onto postgres in future.
I think the real downsides are scaling and performance but there are options at least. Given that TouchDB is essentially couchdb mapped onto sqlite I do wonder if there are going to be good options to map couchdb replication onto postgres in future.
Thanks, I see. Ok, if it's just string or binary based it will work from a correctness standpoint. I'd expect big performance problems with ad-hoc views (if they even exist here), but these shouldn't be used in production anyways. Also, I'd expect replication to take quite a bit longer because it needs to map every document with changes, so there's going to be a tradeoff between initialization time and replication time between the two approaches.
I'm thinking it's going to be beneficial for larger databases to have a TouchDB 'server' somewhere, which constantly replicates with CouchDB and sends the devices a complete snapshot sqlite file for the initial setup. After that, they can talk to CouchDB directly. Otherwise it could take like half an hour to initialize a 50MB DB on a device, which is not really feasible.
Yes definitely do that. I bundle the sqlite in the app store updates and then mount that as an external db and pull from itself - its a bit awkward but it worked. I had to write the external db stuff, but it was pretty easy.
The use cases I have in mind don't need the DB to scale to more than a few ten thousand users. Should be ok with a two or three replicated nodes I think, from my experience with Lotus Notes.