This past week was the MVP Summit in Redmond, where Microsoft entertains and informs the people on whom it has recognized as MVPs for various products. I didn't attend this event as I've been out of town a lot in 2013 and wanted to remain at home. I also didn't have high hopes that it would be particularly informative given the relative close proximity to the next release of SQL Server 2014. However many others did and there was one item that caught my eye at the end of last week.

Greg Low wrote a blog about an option in SQL Server 2014 to place part of your database in the cloud. Essentially you could put a filegroup or file in a location accessible by a URL and use that when creating your database. There is documentation on this up on MSDN and you could test this if you have CTP2 and want to experiment with the effect of having a portion of your database on-premises and a portion in Azure.

Dr. Low includes a couple of places where this configuration might make sense in his blog. The first I agree with. If you are using your database in Azure, then accessing some of the files via a URL makes sense. The second? I'm not so sure. The documentation talks about how or why you might do this, but there's one key element I don't see mentioned: performance. What happens if the Azure connection drops? What happens if it's very slow? If my queries were returning to users asynchronously, from separate batches, I would see some benefit here to clients, but if they don't get results until my local files AND my cloud files return data, I'm not sure I'd pay that penalty.

I'm glad this is an option, and I'm sure there are places where this makes sense. I'm just not sure one of them is some of the tables in my database on premise and some in the cloud when they're being joined together.