No transactions? Single-threaded? Global lock?<p>Don't want to put anyone's work down, but at first sight this looks much more like MyISAM than InnoDB - and just like this, MyISAM's a helluva lot faster than InnoDB for single writer workloads throwing ACID out of the window.<p>Just that MyISAM is battle tested over the course of several years. Again, interested to see what comes out of it, but if history is a lesson, it's usually easier to go from correct to fast (PostgreSQL) than from fast to correct (MySQL et al.).
The upscaledb FAQ indicates "it is not yet concurrent; it uses a big lock to make sure that only one thread can access the upscaledb environment at a time".<p>InnoDB is designed for concurrency (using MVCC, granular locking, etc) so I'd expect it to be slower at single-threaded workloads than another engine that skips all that.<p>Only using single-threaded benchmarking is a bit misleading, imo. This is mentioned in the article but only in a small bullet point towards the bottom.
Performance is great, but what is more interesting is maintaining that performance in the midst of failures and things going wrong.<p>I don't know anyone who chooses InnoDB and says "gee I wish it were faster". While it isn't the fastest show in town, it is a known quantity, and how it breaks is well understood.<p>So if I was going to use a different storage engine, would want something more than its a bit faster, in some cases.<p>Having said that, what a wonderful amount of work, and don't stop hacking on it!
I think this could be pretty neat, it'll be interesting to see how it evolves. However, looking at the comments people have left here I would suggest putting up a table/comparison with InnoDB side by side, detailing which features are implemented, which are not and which are but aren't available through the SQL layer yet.<p>This would also put the "compatible with InnoDB" thing in perspective for people and potentially clear up some other confusion.