I've seen a lot of these new SQL databases, and they all seem to compare themselves to MySQL. That seems like a particularly easy target, since MySQL's main strength is speed, and it's a fundamentally old-school (ie slow) design which has sacrificed everything else to get half-fast. What I'd like to know is how any of these compare in features and reliability to the featureful, reliable databases like Oracle and Postgres.<p>(For specific examples that I've run into recently: does it have geo-spatial extensions, and does it crash and burn and corrupt all its data if a malloc() fails)
This company was probably an extremely easy investment decision:<p>1) Facebookers: Check<p>2) Data Scaling experience: Check<p>3) In-Memory with SQL semantics: Check<p>4) New-York based software that can be sold to quant funds: Check<p>I'm excited. It's downloading now.
Is this a joke?<p>Data must fit in RAM, no joins over >2 tables, no transactions, no builtin support for clustering/sharding/horizontal scaling whatsoever.<p>What is the advantage over memory-tables, MySQL on a ramdisk or something purpose-built (redis)?
MemSQL does not yet support JOINs on more than 2 tables. [1]<p>1. <a href="http://developers.memsql.com/docs/1b/sql/join.html" rel="nofollow">http://developers.memsql.com/docs/1b/sql/join.html</a>
How it compares to VoltDB, which used similar approach and already "combines the proven power of relational processing with blazing speed, linear scalability and uncompromising fault tolerance" (according to VoldDB website) ?
There's another in memory mysql replacement whose name escapes me right now. How are they doing?<p>Ycombinator seems to have backed a few of these next-gen databases. It will be interesting to see who wins.<p>EDIT: Rethinkdb. But it looks liked they've dumped their mysql engine and gone to a pure key-value store.
I'm obviously missing something. Is SQL really the bottleneck for SQL performance? I'm not sure how much compiling down to C++ will help.<p>Is there more to this than the article suggests?
Why should I use this over MySQL Cluster?<p>MySQL Cluster is lock-free, distributed, HA, and has better performances:<p><a href="http://mikaelronstrom.blogspot.com/2012/05/mysql-cluster-72-achieves-43bn-reads.html" rel="nofollow">http://mikaelronstrom.blogspot.com/2012/05/mysql-cluster-72-...</a><p><a href="http://mikaelronstrom.blogspot.com/2012/05/mysql-cluster-727-achieves-1bn-update.html" rel="nofollow">http://mikaelronstrom.blogspot.com/2012/05/mysql-cluster-727...</a><p>And MySQL Cluster has been used in mission critical apps for years.<p>What does MemSQL give me that MySQL Cluster doesn't?
Question - how well does the query parser handle stale queries? SQL Server for the longest time had issues with plan stability in that the plan became <i>too</i> stable. When the data distribution changed dramatically, the queries didn't age out of the cache and the queries would do such things as use the wrong index, or not work out the correct cardinality of a table and then use an index where really a full table scan would have been better... and so on.<p>How does the database handle this sort of thing?
Looks useful. Drop in mysql compatibility is a huge plus for many projects that are tied to mysql (for whatever reasons).<p>Does anyone know if there are any plans for having MongoDB style replica sets (e.g. sharded and replicated databases in a cluster)?<p>Also, it would be great if it supported the native mysql replication, so you could have MemSQL replicas of a master mysql DB.
Why not just use objects in your favourite shitty OOP language as usual and take regular snapshots of the data in memory and save them to disk as rollback points instead? Bam! Nothing new to implement in the application. Bam! Lightening fast access and write times. Bam! Data persistence.<p>Bam!