Oh, one more thing: Did you ever load multiple TouchDBs? I'm thinking the overhead per DB (not per server) should be pretty small, no?
Background: I'd like to build an application where I separate entities into multiple couchDBs, partly since it saves me view definition code, partly because it gives me more flexibility for per-document access permissions.
- is document based
- can easily replicate to laptops and embedded devices
- has all the security I want, e.g. encryption, per document security
- has the bindings I want and/or a new binding can easily be implemented ad-hoc
Given the advantages and disadvantages I'm leaning towards CouchDB and rolling my own security wrapper. IMO that's still better than going with an RDBMS and then implementing replication[1]. How do you see this?
[1]edit: and also giving up the document based approach, thus not having arbitrary mapping from the get go.
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.
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.
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.