1. Bulk: Since this table will be very large (possibly millions of rows). Wouldn't worry about that: millions of rows is not much for a decent database. 2. Load: I need to search, add, update, modify entries on this table from multiple providers. Therefore, there is an issue of contention. That's hard to judge without knowing the load on your system, but again, a decently configured DB should be able to handle a 100 or so "upserts" per second, while maintaining decent select response time. 3. Performance: XML is usually very slow. If it's primarily generating XML from the provider data, and putting that into one un-indexed column as "payload", that should not be slow. In fact, generating XML + one column insert is likely to be faster than inserting multiple (indexed) columns. That said, if you're planning to search on the XML content, you should not take this route. You say that the provider data is linked to other data in the system, I assume by relational references - in that case XML is out of the question. Surely different categories of provided data have something in common? If not I would suggest using different schemas (and applications) altogether instead of different tables. My tip is to do a little bit of application analysis. Try to find the common patterns in the different data structure categories. You should be able to fit it into one or two base tables that cover 80% of the provided data. Check out (ask your users and log application queries) which data is most relevant - it's not likely to be a lot more than the 80% common ground you'll already have. Put a layer in between provider input and the database that massages the data and puts it in the 80/20 tables, properly indexed and related to the other data in your schema. For the remainder of the data you can either choose your XML approach (if it's not going to be heavily searched) or use an auxiliary column table with essentially 3 columns: 1 FK to the "80/20" record with primary data, 1 FK to a logical column name (from the provider category), and 1 column for the data. Depending on circumstances, you can have various auxiliary table columns for multiple data types, or just one auxiliary with multiple data columns for each data type