1.) It is :-)
2.) Not in my experience, but it depends of course what "scale" means to you. 9Gig Data.fs works fine for me, no idea if 1TB would be useable. The 9Gig is also without blob support, once that goes into the app, it will be a lot smaller.
3.) Versioning (aka "built-in undo") has saved my sweet butt a couple of times. Packing is really painless, never ever failed for me in many years. My incremental backup scripts include a packing / full backup cycle every few months.
4.) Never ever cracked for me. In my experience ZODB is a tough sucker. Many years of work on ZODB probably make a lot of difference to the newcomers in the robustness department.
Don't forget that on ZODB, the case stated above ("Once we store a document in CouchDB, we modify it at least twice after the original write") would result only in one write if it was in the same transacation. Not quite clear from the description if they're talking about multiple transactions there.
Proper setup of objects also means that not all edits write a huge object to the DB, ideally only a small subobject.
Comment
All valid points. I think to me the interesting thing to take away from this is that I can "apply" my experience of ZODB to CouchDB. In a sense.
I wonder if CouchDB has the same delicate challenges with conflict errors as ZODB has.
Parent comment
1.) It is :-) 2.) Not in my experience, but it depends of course what "scale" means to you. 9Gig Data.fs works fine for me, no idea if 1TB would be useable. The 9Gig is also without blob support, once that goes into the app, it will be a lot smaller. 3.) Versioning (aka "built-in undo") has saved my sweet butt a couple of times. Packing is really painless, never ever failed for me in many years. My incremental backup scripts include a packing / full backup cycle every few months. 4.) Never ever cracked for me. In my experience ZODB is a tough sucker. Many years of work on ZODB probably make a lot of difference to the newcomers in the robustness department. Don't forget that on ZODB, the case stated above ("Once we store a document in CouchDB, we modify it at least twice after the original write") would result only in one write if it was in the same transacation. Not quite clear from the description if they're talking about multiple transactions there. Proper setup of objects also means that not all edits write a huge object to the DB, ideally only a small subobject.