what it comes down to, IMO, is the typical enterprise conservativism. enterprises embrace new technologies slowly (if at all, in some cases), and the data layer (unlike the application layer, one could argue) has *always* been a strategic decision. that caution, however, is increasingly being tempered by a willingness to consider that in some situations, an RDBMS is perhaps not the only hammer for that nail. perhaps your experience at Software AG was different, but that – to us – is very different, because it could herald the entrance of non-relational (XML or otherwise) data stores as a mainstream option.

to answer your last question, it's not about products, it's about need. given that the relational market is fairly competitive, we have yet to speak to anyone who's considering alternatives for the sake of considering alternatives. instead, it's driven by needs that are not being satisfactorily met. whoever supplies that functionality will be considered – vendor, open source, or otherwise.

Hmmm … it seems to me (although I spent most of the last 5 years at Software AG so I might be biased) that developers loosened the relational shackles some time ago. (C. J. Date and the other cheery folks at dbdebunk dot com of course think developers never locked themselved in the shackles in the first place, but that's another matter). In any event, multivalued databases (e.g. Pick) and OO databases have been around for a long time, and XML DBMS are fairly mature after 5 years or so. Now the major DB vendors are introducing "native" XML capabilities, merging in full text capabilities, and so on. Are people looking for RDBMS alternatives, or expecting "databases" to handle all sorts of structured, unstructured, and semi-structured data within the same products, APIs, etc.?

i would probably take exception as well that only the time component differs; one thing we're seeing more of is efforts to prioritize based on payload information: giving voice packets a higher priority, for example. storage, on the other hand, has had these notions for a long time – and of late we've seen things like Centera and DR450 take that to the next level.

but on the last point, we're definitely in agreement: choice is definitely a welcome development, but brings with it substantial responsibility.

to put it another way: no one gets fired for going with a relational DB, but you might for picking something new. the trick, as always, is to understand the relative merits, strengths and weaknesses of individual platforms and to design accordingly.

All that said, developers still need to be aware of the fact that different storage mechanisms have very different tradeoffs in terms of reliability and performance and indexability and so forth. Yes, choice is good — but choice needs to be educated, or we users will all suffer.