I have been off the blogs for a while and recently changed roles in Microsoft to be an Industry Technical Strategist in our Worldwide Financial Services practice. I guess I picked a great time to move into our Financial Services practice. :)
One of my passions in my previous roles was around SQL Server and specifically SQL Server in Line of business applications.
Let’s give a little history
Previous to working at Microsoft, I worked with SQL Server, Sybase and Oracle back in the SQL 4.2 and 6.0 days. Anyway, back then SQL was a database that fit in between Jet(Microsoft Access and Foxpro) and Oracle. It was mainly focused at department level internal applications while Oracle and Sybase were focused at larger workloads. SQL Server was typically easier to use, manage and install than its counterparts.
Starting with SQL 7.0, we focused on larger workloads and starting competing in TPC and other benchmarks and expanded this through SQL 2000. We started catching the competition and still had the ease of use and deployment.
Then in SQL 2005 and 2008, we really expanded and are able to handle pretty much any large business workload and the largest most scalable applications. We added reporting, OLAP, and enhanced integration capabilities and moved into data warehousing in a big way. At the same time, we still kept the ease of use, manageability, deployment and installation.
A funny thing happened along the way. We learned some big lessons along the way and added features to handle a world where servers need to be online 24X7. Features such as Replication, Clustering, mirroring were added to address availability. Table partitioning and larger 64-bit servers were added to handle the normal mainframe workloads.
Today
In the past few years, almost every customer I talk to still has a leftover view of whether or not SQL Server can handle their LOB solutions. I think this is still a leftover view of SQL's early days where it wasn't viewed as a mission critical database. So as my first post in a couple of years, I wanted to start adressing these questions in Financial Services
SQL Server in Mission Critical Workloads
Here are a few proof points you may want to view when looking at SQL Server in Financial Services.
What about the really high throughput workloads like Stock quotes and lookups. Can SQL handle thousands of updates per second?
Townsend Analytics runs on SQL 2005 and handles 60,000 quotes per second inserted into a DB and 100 events per second.
http://download.microsoft.com/download/d/d/7/dd79c390-5b75-45fb-a0f5-2359a6d20643/GEMS4641/Townsend_Analytics_SQL_Server_2005_Launch%20Case_Study.doc
Citi handles 200,000updates per second
http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000001199
My point is that Microsoft SQL Server is the backend of exchanges, ticker plants, and Market research data.
What about Line of business applications with thousands of concurrent users?
Yes, we handle those as well. How about Progressive who moved their Policy Admin System to SQL 2005 with ~27,000 concurrent users? (http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000002133)
My point here is that we work handle the workloads of things like teller solutions in banking, Insurance (claims and policy management), and capital markets (Trading stations) we handle workloads of thousands of concurrent users who are always logged on.
What about online sites? Online Banking? Online investments? Insurance quotes?
How about Marketwatch?
http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=200969
We handle many of the online banking portals, securities portals and Insurance portals. Anyway, we have too many case studies to list, but today we handle the largest workloads with thousands of updates per second and thousands of concurrent users.
What’s next?
My next update will talk about reporting and data warehousing and finish off with how do you build solutions with SQL Server that are scalable and highly available.
