February 10, 2014

MemSQL 3.0

Memory-centric data management is confusing. And so I’m going to clarify a couple of things about MemSQL 3.0 even though I don’t yet have a lot of details.* They are:

*MemSQL’s first columnar offering sounds pretty basic; for example, there’s no columnar compression yet. (Edit: Oops, that’s not accurate. See comment below.) But at least they actually have one, which puts them ahead of many other row-based RDBMS vendors that come to mind.

And to hammer home the contrast:


12 Responses to “MemSQL 3.0”

  1. Eric Frenkiel on February 10th, 2014 4:19 pm

    MemSQL’s column store most certainly has compression.

    Check out some of the features of MemSQL 3.0 here: http://www.memsql.com/technology/

    -Eric Frenkiel, CEO MemSQL

  2. Curt Monash on February 10th, 2014 5:33 pm



    Actually, I never said MemSQL didn’t have compression. I just made accurate reference to what was said in my last phone call with your guys, then completely forgot that you’d sent an email correcting the error. My bad! 🙁

  3. A on February 19th, 2014 6:53 pm

    Link less to your own articles and more to that actual item of interest (MemSQL). Shouldn’t need a link in the comments to actually get there.

  4. Curt Monash on February 19th, 2014 7:47 pm


    I’m terribly sorry that this blog — which I provide entirely for free and at my own expense — doesn’t meet your requirements. Perhaps some other one would suit you better.

  5. John on February 20th, 2014 7:15 pm

    Curt, Soundslike memsql is ROWSTORE in memory and then converts into columnar storage on disk? if thats the case, whats the query engine optimized for ? columnar or row?

    Don’t think any one vendor has been able to do a single query engine for both row and column just yet. If you just store columnar and has row based query engine then memsql is probably a wannabe columnar.

  6. Curt Monash on February 20th, 2014 9:09 pm


    Be a little careful when you say that a single query engine can’t handle both row and column operations. When it comes to query planning (including optimization), I think the problems are generally surmountable. Ditto ancillary features such as backup and so on.

    Caching is a tougher one, but MemSQL is a special case in that regard as 2 of its 3 table types are fully in-memory anyway.

    All that said, MemSQL’s columnar features are new and immature. Any stereotypical doubts you have around maturity I’d be likely to share.

  7. John on February 20th, 2014 9:18 pm

    Curt, I would humbly disagree with you on this one. Greenplum adding columnar storage to their Row base database didn’t really make them columnar compared to Vertica/ParAccel as an example. I understand the immaturity of memsql columnar but query executions of row stores on column storage don’t yield the best results. In any case, as usual you have done an impressive job by providing perspective on such technologies and appreciate that.

  8. Curt Monash on February 20th, 2014 10:24 pm


    What you’re describing as Greenplum weaknesses falls within the scope of what I was suggesting.

    Even an elementary column store has reduced I/O — compression aside — plus the tendency to compress better than a row store (assuming the same compression algorithms, especially columnar compression algorithms). Saying “Yes, but Greenplum still gets smoked by Vertica and ParAccel” doesn’t contradict anything I’ve said.

  9. Keshav Murthy on February 22nd, 2014 11:32 pm

    Curt, John,

    wrt, “single query engine for both row & column store”, DB2 BLU has a single engine which stores both ROW or COLUMN store tables and supports queries on them, even joins. See the paper at: http://researcher.watson.ibm.com/researcher/files/us-ipandis/vldb13db2blu.pdf

    Even in Informix with Warehouse Accelerator, presence of two engines is transparent to the application. Acceleration & query compensation happens automatically & transparently.

  10. Curt Monash on February 23rd, 2014 12:41 am


    The question isn’t transparency; MemSQL has that, and so do Greenplum, Aster et al. It’s whether each part is as good as one would expect a dedicated product to be.

    My take on BLU was http://www.dbms2.com/2013/05/27/ibm-blu/

  11. NoSQL vs. NewSQL vs. traditional RDBMS | DBMS 2 : DataBase Management System Services on March 28th, 2014 1:18 pm

    […] of memory-centric DBMS flag-wavers MemSQL, Aerospike, and SAP HANA Categories: In-memory DBMS, NewSQL, NoSQL, OLTP, SAP AG  […]

  12. MemSQL update | DBMS 2 : DataBase Management System Services on May 1st, 2014 11:40 pm

    […] … which was the point of introducing MemSQL’s flash-based columnar option. […]

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.