The joy of schema less development

as the author of a schema less database, i find myself in the strange position of the barefoot shoemaker. i need to explain a bit. our current storage engines, esent and munin (which was designed mostly to be like esent) have rigid schemas. there are tables, and indexes, etc. this means that features that touch the storage layer tend to be much more complex. they require migrations, adding new features that require storage means that we have to create new storage tables, or modify indexes, or any number of a bunch of stuff that we developed ravendb so our users wouldn’t have to .

i have been working with our managed implementation of leveldb quite a lot lately. in order to do more than merely write tests for this, i tried to create a feature complete feature, an aggregation engine. the code is not production worthy (yet!), but what struck me quite hard was the fact that except for the fact that the storage layer is full of bugs (well, that is why i was writing stuff on top of it, to expose it), i had a blast actually working with it.

i could make modifications & changes with hardly any friction, and it was a real pleasure to start working with things in this fashion.