Before I continue on with any other posts on this blog, I have to lay some very exciting groundwork.

I said in my bio that SharePoint can be architected to scale from a single server installation that handles just a handful of static documents to extremely large implementations consisting of multiple farms that can handle 50 terabytes or more. 

Well, this is statement requires a bit of qualification.  I have been part of architecture teams that have loaded 10s of terabytes into SharePoint.  This is absolutely possible and I have actually developed a content load utility that can blast 50 million documents into a properly architected SharePoint system in just a couple weeks.  But the problem isn't putting data into SharePoint.  It's making sure you can get it back out.

I've always been concerned about the 50 million document limitation for an index server in a SharePoint farm.  Sure you can have multiple farms.  And with the MS Search Server 2008 we can even do federated searches to aggregate results.  But the problem comes with relevance.  I can certainly write code that kicks off searches on multiple farms and aggregates the results but I lose relevance.  Without the internal ranking engines talking to each other, all we get is a group of unranked links munged together in some sort of list.

Enter FAST.  With the recent acquisition offer for FAST, things may change a bit.  I listened to the tele-conference call.  They didn't want to come right out and talk about the implications that FAST would have on SharePoint, but I think it's pretty obvious.  Heck, SharePoint has been playing nice with FAST since July of last year!  All the sudden, SharePoint is a player in a much LARGER market.  My dream is that FAST technology be baked into SharePoint or at least so closely aligned that we won't be worrying about millions of documents anymore.  We'll be talking about BILLIONS of documents.