SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need to devise a solution strategy for an internal application that will take inputs from rfid tags and those records will to be stored "somewhere". Now this somewhere needs to be choice a between a SharePoint List or a SQL Database. High volume transactions are expected on this.

Reports and views will be created for the concerned stakeholders on these recorded transactions depending on the required business logic. While, SharePoint is the obvious choice for the presentation layer , considering the plethora of options I get using list views , content query , reports and performance point dashboards and I am still unclear about using a list to save the data or use SQL Database.

By high volume I am expecting around 20k new items/day.

share|improve this question
up vote 8 down vote accepted

I'd go for the SQL database. For several reasons:

  1. Storing into SharePoint list adds a lot of overhead that you don't need.
  2. With 20K items per day you'll reach the supported max in 15000 days and list throtling limit in 6 hours
  3. But most important with that amount of data what you want to get out is aggregate to make sense of the data. And this is the area where SharePoint really is lacking compared to SQL
share|improve this answer
I would also go with the SQL database option. You can always pull that data into SP using BCS and External Content Types. – Hossein Aarabi Oct 16 '12 at 20:18

I would, and have in the past, use a separate SQL database to store all of that data. This will require additional work for the presentation of the data, but using BCS, SSRS and/or PowerPivot, you can pretty easily pull that into SharePoint. I wouldn't put that much into a SP content database and expect good things ;)

share|improve this answer

It seems that you are planning to develop kind of a 'service' here.

I don't think list is an option, however you could develop this as custom service application that will still be part of the SharePoint infrastructure but underneath it will utilize service database.

ParagoService is a good example of custom SharePoint service application implementation

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.