The x86 instruction set is the life blood of modern IT.  While it is easy to criticize for it's lack of elegance and archaic nature, the very low end (mobile devices) and the very high end (supercomputers) seem to be the only place x86 is not overwhelmingly dominant.  Many other platforms like Spark, MPS and even Intel's own Itanium are not longer viable options for the overwhelming majority of applications.  The platform is very prominent in the very high end and is making inroads into the mobile market currently dominated by ARM.  Apple, a long time PowerPC company, recently shifted to x86 and with enormous success.

Is x86 the best architecture? Nope.  The fastest or the most power efficient?  Not even close.  The great x86 advantage is that trillions of dollars have been invested into it in terms of software, hardware, expertise and intellectual capital.  A platform shift today would require more investment than the government bailout of wall street. 

A decade a go the industry did a lot of soul searching in terms of figuring out what's important in the server world.  Was it 64-bit? low power? High IPC?   Lots of threads?  Bandwidth?  Megahertz?  Emulation? In that search new architectures emerged like Itanium and NetBurst (which was x86 based) that just didn't make it.   Companies like Intel, HP and Sun invested billions of dollars creating processor platforms that are uncompetitive with 64-bit multi-core x86. 

Where SQL Came From

SQL was designed for computing needs that emerged more than a quarter century ago.  The hard disk become the ideal way to store large amounts of data and has held that position to date.  Putting data on spinning platters rather than random access memory created many very complex but ultimately solvable problems.  As finance and accounting applications dominated the computing landscape and things like transactional integrity and ACID compliance were crucial.  A young guy named Larry figured out how to monetize this and became one of the richest men in the world. 

Database Needs Today

The types of problems dominating database science today are very different.  Today's applications like google, twitter and facebook simply can not function on the standard relational model on any single server that exists today.  While we still have spinning platters a lot of stuff can fit in memory.  The number of users and is astronomical by 20th century standards.  While a large bank may have tens of millions of customers, they will perform very few database operations in a day.  Most of these are automated and they may actually interface with the system a few times a month for very short periods of time.  Contrast this to an application like facebook.  There will soon be hundreds of millions of users, many of which spend several hours a day on the site.  What's worst is the database operations could involve many parties.  When you process a payment it's between your bank and one other party.  When you post to facebook, everyone of your 10,000+ "friends" may need to be updated.  This if profoundly beyond the scope and scale of the way SQL has traditionally been done. 

New Ways of Thinking

While most of these new applications still have SQL components, the bulk of data exchange is done though new techniques that would be considered exotic and sometimes even blasphemous by SQL standards.  Architectures like SimpleDB, BigTable and Astoria do many things in fundamentally different ways. By sending simple, state-less and sometimes structure-less objects through the web as XML, these platforms solve the basic Create, Retrieve, Update and Delete (CRUD) needs of an application.  While this works for day to day updates, a rich enterprise application has needs way beyond.

The Demand for Strawberry Pop-Tarts

It turns out that demand for strawberry pop-tarts skyrockets right before hurricanes.  Wall-Mart, North America's largest employer and one of the few companies thriving in the current economy not only knows this but aggressively does something about it.  The real power behind SQL is not so much it's ability to store structured data, but how it can transform a business and provide insight into customer behavior over time and across many transactions.   While you could say that such analysis is done with cubes engines or BI tools, they are fundamentally based on relational databases.

The Problem with Data Warehouses

The BI industry has long relied on data marts or data warehouses to solve many problems in order to speed up queries and avoid affecting transactional performance. A data warehouse uses an Extract, Transform and Load (ETL) process to effectively make a copy of production data.  The data is often reduces, cleaned up and optimized but essentially there is a copy process that usually happens overnight.  Social, retail or news events at a much faster pace.  A retailer can't wait until midnight to know what is selling on black Friday at noon on the east coast.

The Solution is SQL

While the SQL language does not do some things like forecasting, it provides the foundation of what modern businesses need to operate in a competive environment.  This is especially true in the increasingly global and highly dynamic times we are in today.  SQL has served us well and needs to shed some remenants of a different era, but will allow us to leverage the trillions that have been poured into sql-based technologies.  Like x86, it has it's rough edges but serves us quite well for many situations and all of the advanced features of SQL need to be brought supported in future cloud-based storage scenarios eventually.