unsexy_database

As enterprise customers start to use your product in many different ways, new feature requests will start to flow into the product team. These features aren’t sexy features by any means, but every enterprise customer cares about them deeply, and we try to include as many customer feature requests as possible into every release, sexy or not.

To really understand these unsexy features, we must examine two areas:

  1. How users derive value out of your product.

  2. How users manage a database product.

In this two-part blog series, we will explore these topics and why they matter in today’s database market.

Part 1: How People Derive Value

Tools Compatibility

At the end of the day, people connect to a database via a suite of tools and apps such as SequalPro, Tableau, Looker, ORMs, database explorers, etc. Ideally, database developers are able to use existing drivers/network protocols that people already understand.

Query Surface Area and Query Optimizer

Super successful products “just work.” A major component of “just working” is having SQL query surface area that supports everything an unsophisticated user can throw at it (e.g. full set of data types, builtin function, subqueries, etc). This can be a hard pill to swallow, but it’s also what makes your business defendable from the barrier to entry standpoint.

This also applies to a query optimizer (QO). The “just works” idea goes out the window if the QO chooses a disastrously slow execution plan. In a way, the job of a QO is to avoid disastrously slow plans rather than finding perfect execution plans. Building a great QO is a hard problem, and MemSQL is constantly improving our QO in every release to ensure that queries run as efficiently as possible. And by the way, from the engineering perspective building a QO is quite a sexy project.

Data Loading

I guarantee that anyone who deals with a lot of data has one major pain: ETL. ETL sucks! You are moving data across different systems and it’s never smooth or fast. Date formats are different, data types don’t perfectly match, NULLs, character escaping, etc. It is all the little things that start to get really annoying.

MemSQL supports a lot of ways of getting data into the database. Obviously we support CSV load via LOAD DATA, as well as a variety of other ways to push data into MemSQL, including out-of-the-box streaming of data from collectd, and statsd to enable machine data performance analytics. Our goal is to help customers avoid ETL as much as possible.

The Little Things

Working on error messaging, language support, character encodings, data type conversions is brutal, as it requires tremendous attention to detail. We write a ton of tests and churn a lot of code that is not groundbreaking, but it has to be done. This improves the lives of our customers and lets them iterate on their applications faster. Precise error messages make application development easier. Character encoding support broadens the reach of the product.

The little things provide what we call a “delight” moment when working with MemSQL is easy and intuitive.

Stay tuned for part two as we talk more about how people manage their databases.