Will SSDs Cause Performance Tuning Experts to Go the Way of the Milkman?

Will SSDs make performance tuning experts irrelevant? Consider the following two quotes before we go any further.

"When a tree falls in a lonely forest, and no animal is near by to hear it, does it make a sound?" –Physics published in 1910 by Charles Riborg Mann and George Ransom Twiss

"If your SQL Server application is not running at peak theoretical speed, and no one is talking about it, do you have a performance problem?" –Brian Moran (today).

Several months ago, I wrote about the $10,000 server of the future ("The $10K Server of the Future"). I touched briefly on the topic of solid state disks (SSDs) and the art and science of performance tuning. This month I want to explore this topic through the filter of how it will impact the careers of the many people who make their living tuning SQL Server, whether it’s by their own hand or by the advice they provide in written and verbal form (i.e., books, magazines, classes, conferences). First, let me say that I’m not trying to pick on these people. I was one of them for 15 years. I’ll always have a soft spot for performance-tuning artists, and yes, it’s as much art as it is science. But consider the following anecdote. I think it will make my thoughts on the topic at hand pretty obvious.

I was talking with my business partner, Andy Leonard, about this topic recently. He shared the following story from a past engagement. (Note that I’m simplifying the story and rounding the numbers to make the point of the story easier to follow.) Andy had been responsible for tuning a complex SQL Server Integration Services (SSIS) process for a large data warehouse. Andy was the project manager and the architect, and he had several other people involved. Weeks of work tuning the code dropped the process’s run time from about four hours to 12 minutes. Can anyone tweet #winning? Sometime later, they added SSDs to the server for additional gains and other reasons. Execution time for the process dropped to about 10 minutes. Just for fun and giggles, Andy decided to run the old version of the SSIS code on the server with the new SSDs. The process took about 12 minutes. Think about that—weeks of work by highly skilled, highly paid software engineers and architects for a net difference of about two minutes compared to simply throwing hardware at the problem. Isn’t throwing hardware at a performance problem one of the seven deadly sins and typically a horrible return on investment (ROI)?

Today, server CPU and memory are so blazingly fast and cheap that it’s not usually cheaper to throw hardware at a memory or CPU problem unless you’re talking about big data. I/O bottlenecks have been the most common type of bottleneck that database performance tuning experts have faced since I joined the SQL Server community in 1990. Until recently, ROI analysis dictated that it made sense to spend a lot of time and energy trying to solve the problem through human intervention and labor. But SSDs will eventually change this ROI math. It’s inevitable.

I had planned to explore a different topic this month when I read a Twitter post by Jorge Segarra (@SQLChicken) talking about the rapid decline of SSDs. Currently, SSDs aren’t as cheap as physical disks, but I think they will be eventually. If you think about it, an SSD is actually a simpler device to build and calibrate compared to a metal box that contains magnets spinning at ridiculously high speeds. Do vendors give away 16G thumb drives based on spinning magnets at conferences? That’s why I think SSDs will eventually be cheaper than traditional media.
Consider the future when SSDs are a heck of a lot cheaper and more widely adopted and a company ponders the following question: “Should we spend weeks of time and energy, and perhaps hire a really expensive consultant to help us fix the problem, or should we spend less money, add a terabyte of SSD, and fix the problem in a few days?” I think that will be like a milkman knocking on your door and asking if you need any milk.

Let me rein this back in a bit before I wrap up. Performance-tuning artists will never go away entirely, and this skill will always be among the most highly paid. But I’m convinced that the natural evolution of hardware will reduce the quantity of performance tuning experts necessary to satisfy market demand. This supply and demand imbalance will create a lot of pain for old-school performance tuning experts who can’t change with the times. But heck, milk is still a big business. We just don’t have it delivered two quarts at a time to our porch.

One final point in hope of reducing some of the flame mail I know I’ll get. Yes, I know that SSDs have been around for decades. I get that. No, I don’t think that magically fast hardware will always make up for horribly written SQL and application code. However, this is the first time I’ve started to see a pattern of throwing hardware at the problem being a decent answer. It was hardly ever the right answer a decade ago. And I know that big data and topics du jour will always push the envelope, and those environments will also need performance tuning artists. But most businesses don’t need big data speed, and we’re quickly getting to the point in which throwing an extra $25,000 into your server will solve most of your performance needs more quickly and less expensively than performance tuning can. Until recently, that ROI math just didn’t exist.

What do you think? (Astute readers will notice I didn’t address the question I posed in my quote in the introduction. I have my thoughts and I might explore this topic at a later time. But keeping with the grand tradition of philosophy, don’t you think it’s a question that you should answer for yourself?)

Are you interested in learning more about the origins of the question “If a tree falls in the forest, and no one is around to hear it, does it make a sound?” Check out the following links for more than perhaps you ever cared to know about the history, science, and philosophy of this question. Enjoy!

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.