Here is my situation:

We are working on a scan-to-SP solution for our remote locations. The scanning will take place throughout the day/night. Our current estimated Total Daily Scans will number around 7,500-10,000 with most scanned documents (PDF) around 1.5 - 2 KB in size (20G / day of documents at max). We will be using a third party back up solution to offload the documents after X weeks / months (TBD). My question is how should we go about storing these documents utilizing our SharePoint environment? Should the docs be stored within the content DB as usual or should we use RBS/BLOB storage?

Thank you


  • What sort of storage are you using? Can you afford to drop 20 GB of data into this storage each day? How many days before you fill up this storage? Also, will you be indexing the PDFs?
    – shufler
    Commented Apr 19, 2012 at 16:52
  • We can and will be able to handle this kind of storage capacity, maintain document security and maintain a high standard of network / dB io performance. We are currently not looking at indexing the PDFs.
    – Jason D
    Commented Apr 19, 2012 at 21:44
  • Jason Have you implemented this yet? Can you share any lessons learned please? We are about to do exactly what you describe, except we are configuring the scanner software to populate the metadata when uploading to sharepoint. I am wondering how many site collections, with how many libraries did you design this. Also, was the Content Organizer able to perform well with 10,000 docs per day?
    – user19395
    Commented Sep 7, 2013 at 13:13

2 Answers 2


While externalizing BLOBs may solve some of your performance concerns it doesn't sound like it is going to solve your core problem which is the amount of content and speed that you are throwing this content into SharePoint. Make sure you heavily review your architecture to ensure you are supporting the database IOPS required as well as understand the software boundaries of large databases.

Externalizing BLOBs is not a solution to get over the 200GB recommendation within SharePoint.

http://technet.microsoft.com/en-us/library/cc262787.aspx#ContentDB We strongly recommended limiting the size of content databases to 200 GB, except when the circumstances in the following rows in this table apply. If you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed this limit.

Refer to this white paper to gain a better understanding regarding managing multi-terabyte content databases with SharePoint 2010. http://www.microsoft.com/downloads/details.aspx?FamilyID=37B1333C-A8D9-45F9-BE78-9212C2CD3641&displaylang=e&displaylang=en

  • Thank you, Cory, for the link. We will NOT be hitting this high of a capacity for at least a year to year and a half (if even that). We will be able to roll this out a little at a time so our infrastructure, testing and capacity management will be tweaked as we move along.
    – Jason D
    Commented Apr 19, 2012 at 21:42
  • Also forgot to mention that we will be creating a site collection and subsequent content db for each remote site. I'm working on some code to create the new content db when the site collection is created for the remote site.
    – Jason D
    Commented Apr 19, 2012 at 21:55
  • Re: the 200 GB recommendation -- this is performance-related (and is a good recommendation). Given that this would be exceeded in 10 days, it's worth pointing out that provided you have the infrastructure to support it you can go over this if you want. Microsoft will support a content database of up to 4 terabytes.
    – shufler
    Commented Apr 20, 2012 at 2:28
  • Yep @shufler, good point. I did include the multi-terabyte white paper in my response as it's true that Microsoft does support the larger databases (that didn't use to be the case). We commonly see clients under plan this level of capacity so I like to be safe. Commented Apr 20, 2012 at 18:43

Go BLOB, thats a lot of documents to be contsantly going in and out of your database. Could cause a lot of performance issues. Also what is the time frame? Keep in mind SharePoint Thresholds of 30 million documents per document library. 60 million objects per content database. See here for thresholds. http://technet.microsoft.com/en-us/library/cc262787.aspx . Are you using a third party tool for scanning the documents in?

  • Thank you, Cory for your response. My assumption here is "time frame" meaning how long do we intend to keep the documents? Here is how our process is going to work: User Scans > Scan to Drop Off Library --> Content Org Rule processes doc and routes --> User is going to edit metadata assigned to documents --> document is routed to subfolder based on metadata --> document remains in subfolder for up to x Weeks --> Document is then archived via 3rd party (evault) My thoughts on this were to use RBS to keep from hammering SQL too hard. (gotta get used to hitting "shift return" - :)
    – Jason D
    Commented Apr 19, 2012 at 19:03
  • Sorry, yes time frame did mean how long to keep the documents. You may have already considered these but other things to think about are how large is your farm, are you intending to index these libraries. Those could all hurt your performance as well. Items still could be getting dropped in. 10000 items a day is a lot of documents for users to enter metadata, would it be more cost effective to have something like KnowledgeLake (which can use StoragPoint for BLOB storage) Granted maybe you have 10000 users and that point is moot.
    – Cory
    Commented Apr 19, 2012 at 19:13
  • (for clarity I rounded) we have 100 locations, each location has an average of 10 users and each user will scan an average of 10 documents a day. I've looked into StoragePoint and I'm currently looking at KnowledgeLake per your suggestion. Thank you
    – Jason D
    Commented Apr 19, 2012 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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