Question: Are there disadvantages of using XML, instead of RDMS? The reason I ask this is because my data is more naturally represented by XML structure, rather than RDBMS. I initially thought of [storing the data in relational database](https://stackoverflow.com/questions/545145/map-xml-structure-to-database-schema), but the lack of flexibility of relational database to handle tree-like data structure was putting me of. So I am thinking about just storing the data in XML.

One thing I fear is performance penalty. While RDBMS can handle large datasets, I am not sure whether the same can be said about XML. Also, the database queries are pretty well-established and fairly easy to use and construct, what about XML queries? I don't know.

I am doing .Net application.

Answer: 
If you are working with XML data, then there is almost no question that you should be looking into a Native XML database.

Two of the most popular Native XML databases MarkLogic server and eXist both provide extremely robust and efficient indexing mechanisms, as well as many of the features mentioned on this list. 

In fact MarkLogic server for many search applications drastically out performs SQL databases, esp on large xml datasets. This is because its built specifically to work with XML and knows the best way to index it, which without normalizing SQL does not.

Based on the current market trend it is apparent that while SQL is not going away, its definently losing market share to NoSQL approaches, especially when document centric data is concerned.

Further details ----

Most, data that humans interact with is unstructured and heigharchal. Normalizing and un normalizing this data into a flat relational structure is not only time consuming from an informational architecture standpoint it also forces us to query the data in a unnatural manner. 

Current Native xml databases, allow mass amounts of unstrcutured (but schema validated) data to be easily added and efficiently indexed.

Using xpath to query these documents is a much more natural way of traversing and extracting data, because the queries are representational of the structure. 

It's also easily transformed using XQuery and XSLT. 

The end result is a higher ROI for developers. You write less code and get more out. I used to write mainly in php/sql applications. Once we moved our architecture over to Native XML and XQuery I was able to replace thousands of lines of code with much simpler efficient and concise XQuery. 

If you have the budget (~250k), check out MarkLogic server. Its is one of the most impressive and scalable database systems ever created and is all Native XML. As far as I know it has support for transactions, rollback etc, and all the other features SQL provides.

eXist (http://exist-db.org) is a open source project that has:

* full XQuery/XPath/XSLT support
* efficient indexing mechanisms
* Built in full text search
* Support for REST/WebDAV/SOAP/ATOM/XMLRPC
* Versioning
Things an RDBMS provides that XML doesn't, more or less in order of importance:

* enforcement of a defined schema (though this is certainly available to XML)
* support for multiple writers
* atomic transactions
* referential integrity
* well-defined query language
* ability to optimize access through indexes, compiled queries, etc.
* role-based security
* triggers, stored procedures, calculated columns, etc.

Plus you don't need to load the entire database into memory before you can access any of it.

XML's an okay serialization format for an object model. It's good for hacking together relatively free-form data models that you can access with XPath, too - especially if you're going to transform that data into XML or HTML via XSLT. And it has the merit of being standard and platform-independent. 

But if you get too ambitious with it, you swiftly get into the kind of territory that results in you writing rants about how terrible XML is. (I'm talking to you, [Jeff Atwood](http://www.codinghorror.com/blog/archives/001114.html).)