Versant's German Viscuso on OLTP Databases
Recently I
reviewed the Versant db4o object database. I used the opportunity to talk to German Viscuso, who manages db4o's developer community, about the database market from the perspective of an object database company. You can read the first part of our interview
here.
Peter Vogel: What market is db4o (and related products) competing in? The database market? The object database market? A different one?
German Viscuso: We're competing in the On-Line Transaction Processing (OLTP) database market, which means the transactional (as opposed to non-transactional) data persistence market. This includes object (ODB), relational (RDB) and XML (XMLDB) databases, among others. For Versant's db4o product, it's mainly the embedded OLTP database market, for Versant's V/OD product, it is the large scale, complex, mission critical OLTP application space.
As it so happens, the ODB API has always included an object caching component, so the ODB API bears a remarkable resemblance to some of the recently released caching market products. So, in addition to the OLTP space, the object database is often used as a kind of persistent and query-able application object cache.
PV: What are the toughest challenges facing db4o in the market?
GV: Awareness. There has been a great swell of new products which deliver "partial" object database features: caching, key-value storage, graph analysis [and] schema-less, unstructured content document management. All of these things are delivered capabilities in object databases and we have enterprise 500 companies who have built solutions in each of these spaces on the object database. But there is a lack of awareness in the general software development community.
These types of technologies are extremely difficult to build, taking years to get right. So many who are unaware of object databases (ODBs) have tackled just one particular aspect of a problem and created narrower solutions. So, technology competition isn't really the problem for ODBs; it's the awareness that ODBs are an option. Typically, when someone becomes aware of the ODB as a choice and tries it, it wins. Our challenge is to increase the awareness so we get tried more often.
Another challenge is that there is so much existing data in relational systems. There must be a way of ODBs to play well in the "data eco-system." Service oriented architectures (SOAs) go a long way to solving this problem, because it's the data service that becomes important, not the technology used underneath the service. In SOAs, the choice becomes more about what is most efficient to implement, has highest stability and gives the best performance.
Posted by Peter Vogel on 08/06/2010