[endymi0n]

No transactions? Single-threaded? Global lock?

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.

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.).

[nine_k]

Version 0.0.1 looks much like an experiment in writing a working storage engine. It lacks a lot of critically important things. It's hard to say anything at this point about any real-world scenarios where this storage engine would be useful.

What concerned me a bit was absence of an interesting and promising general idea behind the implementation, the reason to implement a new engine. Maybe it is there, but the blog post does not say anything about it.

[endymi0n]

Exactly this, I was missing the big picture. Having worked with at least a dozen databases, my claim today is that of Tony Million: Don't be a hipster and just use Postgres. Don't get me wrong, I also work with Aerospike, Redshift, Redis and a few other specialized data stores, but I always know why Postgres wouldn't do there. For any specialized data store, at least provide a rationale where the niche is where that thing is better than anything else that's on the market. Simply claiming it's "fast" without further specifications worked out for MongoDB, but I hope it's for the very last time. Optimization means tradeoffs.

[ignoramous]

Thanks for pitching in. I'd like to know more about Postgres (correct->fast) and MySQL (fast->correct) comparison here. Can you pls share technical links that go in details about these? Thanks again.

[dspillett]

I'm not sure how much of it is still relevant today but in the "bad old days" there were a lot of issues where mysql did things blatantly wrong in the name of speed and the devs & supporters usually suggested pushing fixes into business logic. Examples I remember were transaction support, foreign key issues and bad/no type validation (silently accepting impossible dates like 2016-02-30 for instance).

postgres was at that point already a mature, stable, and pretty much correct RDBMS, but it wasn't as fast for certain workloads (massively read heavy ones with low levels of concurrency, IIRC) or as easy to administer badly (I wouldn't say it was harder to administer well, but mysql was more forgiving to of mistakes by people who just wanted to plug it in and not care).