Data Driver

Blog archive

Is Microsoft Feeling the "NoSQL" Heat?

Think the "NoSQL" movement isn't prominent on Microsoft's radar screen?

Think again. Not only is the company tracking it, some people inside Microsoft have actually jumped on the anti-SQL bandwagon. This came to light when Microsoft Technical Fellow Dave Campbell took some pot-shots at the latest threat to the company's bread-and-butter database strategy during the recent Professional Developer's Conference.

"The relational database model has stood the test of time," the database guru said in an interview with Charles Torre on Microsoft's Channel 9 video feed from PDC. "And it's interesting in that there's this anti-SQL movement, if you will," he continued. "You know some people follow that. The challenge is that you're throwing the baby out with the bathwater. "

Some people? How about your people? Here's an exact transcription of his subsequent remarks:

"I've been doing this database stuff for over 20 years and I remember hearing that the object databases were going to wipe out the SQL databases. And then a little less than 10 years ago the XML databases were going to wipe out.... We actually ... you know... people inside Microsoft, [have said] 'let's stop working on SQL Server, let's go build a native XML store because in five years it's all going....'"

Campbell, and others during the show, pointed to the cloud as Microsoft's answer to the future of database technology.

He said, "I think a lot of people in this anti-SQL movement, they're really looking for the cloud benefits, and the thing that we're trying to achieve with SQL Azure is to give you the cloud benefits, but not throw out the model that has worked for so long and people are so familiar with. So [we're] trying to retain the best of both worlds."

The "NoSQLers" weren't his only target. He also took some shots at a certain unnamed company trying to get with the "database service" program.

"Another company made some noise ... tried to make some noise in front of our noise, a week or two ago, by announcing what they're calling a relational database service," Campbell said. "All they did is they took a relational database server and they stuck it in a VM, okay. So you still have to buy the VM. So if you've got a very small database, and you want to run it for a month, you're paying like 11 cents an hour or so. The smallest database you can get up there, is approaching $100 a month, just to have it, because you need to rent the whole infrastructure to go off and do that."

I don't know what that unnamed company is, but I found this announcement interesting: "Introducing Amazon RDS - The Amazon Relational Database Service." This came in an Oct. 26 blog posting on the Amazon Web Services Blog page.

Campbell went on to compare the pricing structure of that unnamed service with Microsoft's database service: "Our cost of SQL Azure in a 1GB database is about one-tenth of what you could do in the other thing that was recently announced ... from some other company."

And truth be told, there were some very cool presentations around the cloud and new ways of using data at PDC. I found the Dallas project particularly interesting.

What about you? What do you think of the whole thing? Comment below or drop me a line at Let's talk.

Posted by David Ramel on 12/01/2009 at 1:15 PM

comments powered by Disqus

Reader Comments:

Sun, Jul 31, 2011 Austin, TX

SQL is not going anywhere for a while since every business that I know has some kind of relational database. With that said there are situations where NoSQL is doing a better job. Look at Redis. On one of my projects it is cheaper and quicker to use Redis as a data buffer instead of adding more SQL servers. So it's more like 'use the right tool for the right job' not use the same tool for every job.

Fri, Jan 22, 2010 Brian Pontarelli United States

Relational databases are great for storing relationships. They tend to get into trouble when you run ad hoc queries across many tables with hundreds of millions of rows each. This forces millions of index lookups no matter what you do. If you can think about the data you are querying in terms of documents, lists, sets, and hashes, you will gain massive performance benefits from other solutions. If you can further reduce the data to simple key-value pairs, you'll get even more. Most people don't realize that much of their data can be viewed differently than in tables with relationships. Once you get past that, you open many possibilities. To this end, I find that a hybrid approach is often best.

Fri, Jan 15, 2010 coetsee

Often we forget the little guy, the SMB, in our discussions of the comings and goings of the Internet marketing industry. Sure there are times like this when a report surfaces talking about their issues and concerns but, for the most part, we like to talk about big brands and how they do the Internet marketing thing well or not so well.

Fri, Dec 11, 2009 Dave Kellogg San Carlos, CA

The argument simply because something hasn't been replaced means it never will be replaced is clearly fallacious. At some point, something will replace the RDBMS. That is a certainty. The question is what and when. I have 20+ years relational experience, and a few years of both ODBMS experience and XML DBMS experience so I think I have a good view across the landscape. The noSQL crowd is, imho, driven as much as by being fed up with oligopolistic pricing and customer treatment as it is with relational database technology. Don't forget that. Yes, there's a technical battle, but there's also a we're fed up and not going to take it any more angle. My guess is that RDBMSs will not be replaced wholesale, but more nibbled away by specialized DBMSs that beat them in specific applications like data warehousing, OLTP, real-time streams, scientific data, and XML documents. If you want to see Berkeley/MIT professor Michael Stonebraker's take on this, go here:

Thu, Dec 10, 2009

Don't forget Microsoft is using and contributing to HBase (opensource implementation of Google BigTable), part of the Bing infrastructure.

Mon, Dec 7, 2009 Peter Vogel Canada

People forget that the relational model is just that: a model. In fact, on the hard disk, every RDBMS stores its data in some highly optimized, proprietary format but they certainly don't store data in table. If some database vendor wants to store their data in XML files, they can. But the XML model (like the object model) is inherently more limiting and less flexible than the relational model. The relational model remain preeminent as a way of organizing and thinking about data so that data can be easily combined and re-used. That's not to say there isn't room for improvement. There is a case to be made that the SQL language isn't the best tool for querying relational databases (the founder of the relational model, Dr. Codd, certainly felt so); In "The Third Manifesto" the other guru of the relational model (C.J. Date) made that case that it should be possible to attach behaviours (methods) to columns, rows, and tables. But all of these are just extensions to the relational model which has survived and prospered because it works. And works very well.

Fri, Dec 4, 2009 Trilobyte Canada

Reply to Sorgfelt: In that case use direct queries against the database. In other situations, using objects will be a better choice. The point I am trying to make is that there is no one-size-fits all solution. The current monoculture discourages us from looking at a wide range of approaches. BTW: Most ORM's provide the ability to query the database or execute stored procedures, so you can have your cake and eat it too.

Fri, Dec 4, 2009 Dan McCreary Minneapolis, Minnesota USA

After spending 20+ years on SQL systems I was shocked to learn that they have become dinosaurs compared with really advanced systems like With eXist I can drag 10,000 XML files into a folder and run XQueries on them in under 5 minutes. SQL systems could do this but I think they are at least 10 years away. But I would not have believed it until I tried it myself.

Thu, Dec 3, 2009 vik1066

There are various competitors available now in market of SQL. But the results are not as much efficient as it would be. Microsoft has it's own reputation of products and services and they give best quality to the customers.

Thu, Dec 3, 2009 sorgfelt

Try to do reporting on millions of objects when you have to access each object to get one bit of information. Compare that to accessing a relational table. Unless your objects are structured to efficiently fit your every reporting need, reporting on an object oriented database can be unacceptably slow, and relational wins hands down.

Thu, Dec 3, 2009 Trilobyte Canada

The microsoft tools encourage you put your data and business logic into the database (preferably SQL Server) and use a thin layer of plumbing to shuttle data between the database and the GUI. While this is a reasonable approach in many cases, it is basically a 2-tier architecture that does not play well with agile or domain driven paradigms. My own experience is that this is a slow and klunky way to develop software. I am no enemy of SQL. I helped write an SQL database engine back in the early 1980's. Relational databases are good at many things, but not everything. It seems that we've had a whole generation of programmers (and managers) grow up thinking that the only way to develop applications is the standard VB/SQL/Stored procs approach. There is little consideration of using ORM or alternative data storage techniques - let alone some full-featured application server (e.g. Gemstone). I think the NoSQL movement is all about choice. What we have now is an unhealthy monoculture of mediocre tools and approaches to software development. This cannot be good in the long run.

Thu, Dec 3, 2009 YSLGuru Texas

The RDBMS approach is not going to be replaced by The CLoud or the Object Oriented DB or the XML DB or the next X number of technologies on the horizon. Just because you;ve been using something for a while does not mean you have to find something new to replace it just as much as it doesn;t mean you have to stick with it. I always disliked XML because it was sold as being the solution to everything including Realtional DB and in the end it proved to be simply a good tool among many tools.

Thu, Dec 3, 2009 David Longstreet Baton Rouge, LA.

XML was originally designed for cross platform data communications, and for that it excells wonderfully. Now I know that today, space is cheap, but to use XML as a database is just as bad as using Excel as a database! That's not what it was meant for, and that's not what it's good at. Most of the problems I seem to find with databases is not with the engine or even vendor specific limitations, its almost always a bad database design, or bad data design of the software used to manage the data. However, it's easier to try and switch to a new toy, rather than fix the problems with one you have.

Thu, Dec 3, 2009 Joel Davis Jacksonville, FL

Yes, we have the physical resources available today because they are cheap. But, we've all seen the result in the ever-bloated versions of software that seems to consume these resources no matter how powerful they become. A RDBMS engine seems to make much better use of available resources than XML and, therefore, will continue to be more efficient. The hardware will continue to have a finite set of resources. Better use of these always means more efficiency.

Thu, Dec 3, 2009 Some old guy

Doesn't anybody see that storing data ini text format is a little bit like going back 50 years? It is as if saying: we have plenty of room for storing punched cards and we built some very fast punched card readers/punchers, so let's go back to punched cards. As for storage size, storing a float 1.234567 will take 4 bytes in a RDB, while storing it in XML like will take aboou 20 bytes (oh, sorry, I forgot about Unicode, it's 40 bytes!)

Thu, Dec 3, 2009 Paul Morris Canada

Ever heard of Lotus Domino? NoSQL databases bear a strong resemblance to the Domino model.

Thu, Dec 3, 2009 Louis M. Mezei United States

I've always wondered about the wisdom of using XML files in place of things like SQLExpress. SQL is self-managed and takes a lot to corrupt records. If they get corrupted (which is extremely rare), there are really good tools to fix the corruption. I don't think XML offers that. My experience with XML is that it can become corrupted and once it gets corrupted, you are in really bad shape. Good example: put an illegal character in XML and you can't read the entire file. Then you need ot manually edit it. And, SQL pretty much takes any character. There are a lot of illegal characters in XML.

Thu, Dec 3, 2009 Ron Sellers United States

I designed my first database application in 1982 so I have also had a number of years of experience. The fact is that the relational database model was designed in times when storage and processing capacity was scarce. A better model will also account for the fact the development and management resources are also scare commodities. The relational model served it’s purpose and is still very useful in the right application, but we need a new model that is designed for the current environment (as opposed to a model that was designed in the 1980s and early 1990s).

Thu, Dec 3, 2009 Nick USA

@Jason Yeah, that global search thing is something I've wanted for a while. What's your current technique? Mine is a stored proc that uses cursors and the INFORMATION_SCHEMA.COLUMNS table. It is slow and uses TONS of memory. Always on the lookout for a better way.

Thu, Dec 3, 2009

Wow. Lots of folks off here. Even the guy from MS. At amazon u can put a db in a vm, but Amazon RDS doesn't do that. Yes digital and the old DecVax had great stuff beyond the relational model dbmss. It should continue to stay around, but the SQL syntax needs a little more tweaking, like changing the position if the from clause. Lastly, the cloud needs a distributed RDBMS, which ms did not build and their azures platform can't support. Yeah, big oops.

Thu, Dec 3, 2009 Jason P Sage Ellington CT USA

I too have used SQL databases for years; they are slick and quick when used correctly. If you want to own your own data and not invest in various "cloud" creations from the big guys who want nothing more than to hold your data... fine; do it. Shoot; we host open source CRM systems ... but we don't market as a cloud solution; just your software and data on our servers - take them anytime you like... we really believe in keeping vendor lock-in to a minimum to allow people to be agile. If you want speed? I've seen the fastest data storage and retrieval from ISAM systems on Mainframes such as the file system used by DiBoL (from Digital originally now owned by Synergy - not talking about their windows based stuff... the Unix stuff!) I can not believe how often in technology folks throw out tried and true tested code and systems for some new fangled toy that really doesn't bring real value while being untested. The one thing I wish SQL and relational databases had that some may already have is a way to do a global search (optionally specifying tables, columns, or nothing at all beside the text or number you're hunting for) that would (without slowing the works down) would return all the tables and columns where "hits" were found... like a google search on your database. The best way to prevent vendor lockin is using databases and writing code that can migrate one system directly to another. Strangly enough, Jegas, LLC is working on such a tool and it's available now: This very tool can currently migrate FrontRange Goldmine Data to Microsoft CRM, Microsoft CRM to vTigerCRM to name just a few of the things it CAN do because these systems all share a similar storage paradigm. Just bewary folks - XML means more parsing and adds bloat. ODBC has been around forever (thanx Microsoft!) and that is faster at sending information. XML is great for inter-process communication over the wire, but as a fast data storage and retrieval mechanism? No way. I hear about folks saying SQL is dead, the big boys are using huge single row flat files etc... Fine. This is when data is not normalized and frankly is the fastest storage and retrieval you can do (with a technique called block reading/writing). But it's not new... and it's also not right for every situation. Relational databases suffer or succeed based on how well the designers of the database put things together for the systems needs. Poor design.. may result is dijointed data, slow systems, etc. Well designed databases can purr. Databases can be designed for speed or for space and relational efficiency; there are pros and cons of each and designing systems that are a mix of speed and efficiency should be the norm. AntiSQL all you want... Next you'll want to improve on H2O :)

Thu, Dec 3, 2009 Gustavo Mendoza Lima, Perú

It have been this way all the time. Mediocre people without skills on a topic are its worst critics.

Wed, Dec 2, 2009 Patrick Wood United States

Without a sound SQL relational database model the cloud will become a fog.

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.