We use MySQL a lot at Sprout Social. NoSQL is throughout our stack too; Cassandra, HBase and Redis are very important to us for niche problems. But MySQL is our workhorse and we power many parts of our platform with it.

With the database world finding an equilibrium between relational and NoSQL, I want to share some thoughts on why we still use MySQL and why we always will. I don’t mean to argue against other databases, relational or otherwise. Technical choices should be grounded in business need, and so I will intentionally keep this high-level. We can get into the weeds in another post or on twitter.

To start, it’s economical; that’s to say it offers a nice balance between scalability and performance. Get yourself some modest hardware. Shove in 100s of GBs of diverse data: many tables of all shapes and sizes that are queried together, separately and in all sorts of ways. Now, hammer that system with 100s to 1000s of reads and writes per second. Under said conditions, MySQL can perform brilliantly, with response times in the 10s of milliseconds. I say “can” because it always depends on the circumstances.

And that leads me into my second point: awareness. It’s the devil we, at Sprout Social, know and trust, which I always prefer over the devil I don’t know. We’ve been burned jumping on something shiny and promising only to discover what makes it buckle. And that’s not to say MySQL is flawless. I think of technologies like a musical instrument. You can make any sound bad. When you know how to play the guitar well, why attempt a concert with a banjo? With technology growing out of the pure sciences, we often forget that much of engineering is an art or, at least, heuristics. We humans always perform better in well known circumstances than in newish ones, no matter how well prepared. In the words of Ron Burgundy, “… it’s science.”

My point is, our team knows MySQL a little like an experienced musician knows their instrument. Our developers can concoct powerful, scalable solutions on the spot. Our ops team can churn out operationally sound clusters like it’s their job. As a team, it’s a hammer we swing with finesse. And that lets us get to the problem at hand of building great software. And, sleeping at night.

One of the hardest problems in software engineering is making the engineers themselves efficient. Try not to over-engineer that one.