Hi, this is my project :)<p>For us this package is most important as the query engine that powers Dolt:<p><a href="https://github.com/dolthub/dolt">https://github.com/dolthub/dolt</a><p>We aren't the original authors but have contributed the vast majority of its code at this point. Here's the origin story if you're interested:<p><a href="https://www.dolthub.com/blog/2020-05-04-adopting-go-mysql-server/" rel="nofollow">https://www.dolthub.com/blog/2020-05-04-adopting-go-mysql-se...</a>
I always found the idea behind dolt to be very enticing.<p>Not enticing enough to build a business around, due to it being that bit too different and the persistence layer being that bit too important. But the sort of thing that I'd love it if the mainstream DBs would adopt.<p>I didn't realise the engine was written in Go, and honestly the first place my mind wonders is to performance.
This seems to be a wire-protocol proxy for mysql -> SQL.<p>The default proxied database is dolt. I'm guessing this is extracted from dolt itself as that claims to be wire-compatible with mysql. Which all makes total sense.
The compatibility (and functionality in general) is severely limited, not usable in production:<p>> No transaction support. Statements like START TRANSACTION, ROLLBACK, and COMMIT are no-ops.<p>> Non-performant index implementation. Indexed lookups and joins perform full table scans on the underlying tables.<p>I actually wonder if they support triggers, stored procedures etc.
I suspect Go is probably better, but as a long time C# developer I cringe at the idea of implementing a DB with GC language. It seems that you would be fighting the GC all the time and have to write lots a lot of non-obvious low allocation code, using unmanaged structures, unsafe, etc., a lot. All doable of course, but seems like it would be starting on the wrong foot. Maybe fine for a very small team, but onboarding new devs with the right skill set would be hard.
It would be great if this evolves to support mysql to postgresql and mysql to sqlite.<p>Then we can finally have multiple database engine support for WordPress and others.
tidb has been around for a while, it is distributed, written in Go and Rust, and MySQL compatible. <a href="https://github.com/pingcap/tidb">https://github.com/pingcap/tidb</a><p>Somewhat relatedly, StarRocks is also MySQL compatible, written in Java and C++, but it's tackling OLAP use-cases. <a href="https://github.com/StarRocks/starrocks">https://github.com/StarRocks/starrocks</a><p>But maybe this project is tackling a different angle. Vitess MySQL library is kind of hard to use. Maybe this can be used to build ORM-like abstraction layer?
How hard would it be to use this as an in-memory replacement for MySQL for testing, let's say, a Rails project?<p>Given how important the DB layer is I would be careful to use something like this in production, but if it allows speeding up the test suite it could be really interesting.
With Vitess likely consolidating its runtimes (vtgate, vtctl, vttablet, etc) into a single unified binary: <a href="https://github.com/vitessio/vitess/issues/7471#issuecomment-2035406575">https://github.com/vitessio/vitess/issues/7471#issuecomment-...</a><p>... it would be a wild future if Vitess replaced the underlying MySQL engine with this (assuming the performance is good enough for Vitess).
shouldn't these projects have a perf comparison table? there was a post a couple days ago about the an in-memory Postgres, but same problem on the perf.<p>if someone is considering running it, they're probably considering it against the actual thing. and I would think the main decision criteria is: _how much faster tho?_