I was hoping for something more specific; am example might be "the query optimizer". Seriously: most everything about a database solution is determined by its storage format, whether it be how it handles concurrency, how it scales, how it handles catastrophic events like power loss, or how expensive it is with regard to memory, disk, and I/O between.
Sitting down and really thinking about what is in, for example, PostgreSQL, that isn't defined by its storage format, the one thing I've come up with so far is query optimization, which I will agree is important, but certainly not /more/ important than the storage format (especially given how many people, even on this site, seem to want to bypass the optimizer, given comments on a recent thread here).
(For a commercial solution I could also see "licensing costs", and generally I could also see "engineering build quality", but that latter notion is unlikely to ever be self reported as "poor, our engineers suck, and we fully expect there to be numerous race conditions in our concurrency code: buyer beware".)
Sitting down and really thinking about what is in, for example, PostgreSQL, that isn't defined by its storage format, the one thing I've come up with so far is query optimization, which I will agree is important, but certainly not /more/ important than the storage format (especially given how many people, even on this site, seem to want to bypass the optimizer, given comments on a recent thread here).
(For a commercial solution I could also see "licensing costs", and generally I could also see "engineering build quality", but that latter notion is unlikely to ever be self reported as "poor, our engineers suck, and we fully expect there to be numerous race conditions in our concurrency code: buyer beware".)