4 ms·

The article should definitely have been clearer - we're not a plugin to MySQL by any means. MemSQL is a completely new database built for modern hardware scena

The article should definitely have been clearer - we're not a plugin to MySQL by any means. MemSQL is a completely new database built for modern hardware scenarios. That means lock-free data structures optimized for DRAM, access patterns, among others. We maintain the MySQL protocol on the wire to minimize friction for existing applications. We really see ourselves as a counterpoint to NoSQL, which has traditionally offered speed but sacrificed functionality. MemSQL is as fast, scalable, yet retains SQL.

saurik 15y ago
I actually understood that you weren't a plugin to MySQL, but the fact that you chose to "maintain the MySQL protocol on the wire to minimize friction for existing applications" is confusing to me, as in my experience the performance-savy database operators did not write their application to target MySQL due to all of the reasons I stated (poor or missing locking and indexing algorithms, such as no hash joins, and an inability to perform partitioning, windowing, or ubiquitous/efficient sub-selects), and therefore your product actually maximizes friction for those seemingly key users (due to MySQL having a horribly unique and generally incompatible take on SQL syntax in some areas, and outright missing functionality elsewhere).
- adw 15y ago
  Think of it as parasiting off the existing library of MySQL libraries for every language under the sun. It's why every key-value store speaks its wire protocol and also memcached.
  - AdamProut 15y ago
    Exactly - The entire MySQL ecosystem remains at your disposal when using MemSql.
  - saurik 15y ago
    So, not using the same actual SQL syntax? Just the binary protocol?
    - tptacek 15y ago
      The binary protocol for MySQL is not, as I recall, particularly idiosyncratic. It's mostly a vehicle for asking the server to parse a text-based query, return a handle, and bind variables to executions of that query (when I implemented it, MySQL didn't even seem to use all the functionality of the protocol).
- pbreit 15y ago
  But MemSQL is targeting MySQL users (at least initially)! Its proposition is more compelling to current MySQL users than it is Postgres (or whichever higher preforming DBs you are referring to) users. And frameworks will have little effort to support the new db and can optimize over time. The whole thing makes a lot of sense to me.

saurik 15y ago

I actually understood that you weren't a plugin to MySQL, but the fact that you chose to "maintain the MySQL protocol on the wire to minimize friction for existing applications" is confusing to me, as in my experience the performance-savy database operators did not write their application to target MySQL due to all of the reasons I stated (poor or missing locking and indexing algorithms, such as no hash joins, and an inability to perform partitioning, windowing, or ubiquitous/efficient sub-selects), and therefore your product actually maximizes friction for those seemingly key users (due to MySQL having a horribly unique and generally incompatible take on SQL syntax in some areas, and outright missing functionality elsewhere).

adw 15y ago
Think of it as parasiting off the existing library of MySQL libraries for every language under the sun. It's why every key-value store speaks its wire protocol and also memcached.
- AdamProut 15y ago
  Exactly - The entire MySQL ecosystem remains at your disposal when using MemSql.
- saurik 15y ago
  So, not using the same actual SQL syntax? Just the binary protocol?
  - tptacek 15y ago
    The binary protocol for MySQL is not, as I recall, particularly idiosyncratic. It's mostly a vehicle for asking the server to parse a text-based query, return a handle, and bind variables to executions of that query (when I implemented it, MySQL didn't even seem to use all the functionality of the protocol).
pbreit 15y ago
But MemSQL is targeting MySQL users (at least initially)! Its proposition is more compelling to current MySQL users than it is Postgres (or whichever higher preforming DBs you are referring to) users. And frameworks will have little effort to support the new db and can optimize over time. The whole thing makes a lot of sense to me.