性能方面也是用户和开发人员最关心的问题。目前关于XML数据库的Benchmark基准还不够成熟，关于数据库交易系统OLTP,分析系统OLAP的基准测试各大厂商已经认可了TPCC,TPCH。而在数据库的XML技术方面，各厂商的支持水平差异较大，目前还远没有达到大家竞相参与Benchmark测试的阶段。目前IBM, Intel所支持的BenchMark标准TPOX已经形成，它针对XML的插入，以及并发用户的读写等形成了一套测试的规范。Oracle目前还没有参与这个测试。
由于Oracle目前对XML支持的能力跟DB2 不采取Native XML的方式路线基本一致。我们做了DB2 9 自身Native XML方式跟Clob和拆分方式的比较，大概来了解不同技术实现下性能的大概差异，由于具体测试的细节很多，这里只摘取几个结果的汇总比较，具体可参考PDF Performance文档：
以下测试结果是基于大批量XML的事务处理的场景下得出，其中包括符合金融规范FIXML的数据。
（1） Clob与 Native XML方式下插入性能的比较：
DB2 Native XML方式下插入需要解析，CLOB插入不需要，但是CLOB方式下为了维护索引所需要的Side Table也需要较多代价。单个用户插入下我们看到维护Side Table的Clob方式效率更低。
另外XML 列可以利用缓冲池，而CLOB则不可以。所以并发插入的情况下Native XML比Clob有更好的表现。
（2） Clob与 Native XML方式下并发查询性能的比较：
Native XML 方式下查询不需要解析，Clob方式下查询需要解析，对资源和时间的消耗都成本不菲。Native方式有明显的优势。
（3） Shredding 拆分方式与Native方式插入性能比较
（4） Shredding 拆分方式与Native方式查询性能比较
最后，引用一个SOA环境下 开发周期比较测试，对比不同XML技术对开发人员的影响：
|
测试项目
|
采用传统关系型技术
|
采用 DB2 9 pureXML 技术
|
|
开发获取和搜索XML信息的业务流程
|
CLOB: 8 小时
Shred: 2 小时
|
30 分钟
|
|
I/O读写数据相关的代码量 (减少65%)
|
100
|
35
|
|
增加新的数据字段
|
1 周
|
5 分钟
|
|
查询
|
24 - 36 小时
|
20 秒 - 10 分钟
|
|
查询未解析的XML元素
|
1 周
|
½ 天
|
SQL Server 2005继续采用Blob保存XML数据并新增了一个XML数据类型，增加了对XQuery和XPath的优化，而且由于在.Net平台对于XML的读取采用了一贯的“Stream”（流）方式，因此相对于应用开发而言效率的损失不够明显，但如果作为混合SQL与XQuery查询时，由于要同时囊括多个XML字段的检索，因此效率较之结构化存储会存在很大的差距。
