There are some IBM references in this post that I’d like to comment on:

– “XML processing” is a broad topic. A specific deployment, although a perfectly valid data point, is not necessarily representative of all XML processing tasks. MarkLogic has a lot of success with “content” use cases, but what about “data” use cases? For instance, I heard of a situation where MarkLogic struggled with insert/update/delete performance in an environment with an extreme number of small XML documents. I also heard of issues with MarkLogic returning very large result sets. My intention is not to pick on MarkLogic here. They are a good vendor with good technology. I’d just like to point out that there are situations where every vendor struggles, and to not put too much weight on those situations unless you know that they closely match your situation.

– IBM continues to be, to the best of my knowledge, the only vendor to disclose XML performance results with *all* details of the workload, hardware, and configuration that was being used (SourceForge: Transaction Processing over XML). IBM also has several customer case studies that substantiate excellent levels of performance, and numerous customers who have spoken about their positive experiences with DB2 pureXML at conferences worldwide.

– Regarding indexing, there is a cost to the MarkLogic approach. As you know, MarkLogic indexes all element values and all attribute values in all paths. And they maintain this index synchronously. This, of course, incurs a cost during insert, update, and delete operations. It is possible that this partly explains the performance issues I mentioned above. In my opinion, the DB2 approach of choosing exactly what you want to index is often better. (Note that to optimize what is indexed does require that you know the queries you will process.)

Also, keep in mind that hybrid relational/XML data servers offer several advantages over XML-only data servers, including:

– Many organizations have existing systems based on relational data and SQL (and ODBC or JDBC). In such situations, a complete rip-and-replace to use an XML-only vendor can be quite traumatic. Our experience is that a hybrid relational/XML store has eased the path to native XML adoption for many such organizations.

– We have also found that many application scenarios are not XML-only, but involve XML and relational data. But, of course, it is natural that our experiences match the areas in which we possibly have stronger synergies.

– Some XML-only vendors lack some of the more advanced DBMS capabilities, like point-in-time-restore capabilities. Also, the established relational/XML vendors do have a wide ecosystem of database tools vendors who work with their products.