from Hacker News

A MySQL compatible database engine written in pure Go

by mliezun on 4/9/24, 7:50 PM with 80 comments

• by zachmu on 4/9/24, 9:29 PM

  Hi, this is my project :)

  For us this package is most important as the query engine that powers Dolt:

  https://github.com/dolthub/dolt

  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:

  https://www.dolthub.com/blog/2020-05-04-adopting-go-mysql-se...

• by jddj on 4/9/24, 8:09 PM

  I always found the idea behind dolt to be very enticing.

  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.

  I didn't realise the engine was written in Go, and honestly the first place my mind wonders is to performance.

• by jbverschoor on 4/9/24, 8:09 PM

  This seems to be a wire-protocol proxy for mysql -> SQL.

  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.

• by pizza234 on 4/9/24, 8:45 PM

  The compatibility (and functionality in general) is severely limited, not usable in production:

  > No transaction support. Statements like START TRANSACTION, ROLLBACK, and COMMIT are no-ops.

  > Non-performant index implementation. Indexed lookups and joins perform full table scans on the underlying tables.

  I actually wonder if they support triggers, stored procedures etc.

• by osigurdson on 4/10/24, 1:32 AM

  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.

• by TechTechTech on 4/10/24, 7:09 AM

  It would be great if this evolves to support mysql to postgresql and mysql to sqlite.

  Then we can finally have multiple database engine support for WordPress and others.

• by didip on 4/9/24, 8:53 PM

  tidb has been around for a while, it is distributed, written in Go and Rust, and MySQL compatible. https://github.com/pingcap/tidb

  Somewhat relatedly, StarRocks is also MySQL compatible, written in Java and C++, but it's tackling OLAP use-cases. https://github.com/StarRocks/starrocks

  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?

• by fedxc on 4/10/24, 12:41 AM

  I always look at these implementations and go wow! But then I think, is there any real use for this?

• by west0n on 4/10/24, 1:00 AM

  Interesting, another project implemented in Go that is compatible with MySQL server, alongside others like Vitess and TiDB.

• by malkia on 4/9/24, 9:00 PM

  Is this for integration/smoke testing?

• by speleding on 4/10/24, 8:18 AM

  How hard would it be to use this as an in-memory replacement for MySQL for testing, let's say, a Rails project?

  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.

• by maxloh on 4/9/24, 9:38 PM

  I know it is a matter of choice, but why was MySQL chosen instead of PostgreSQL? The latter seems to be more popular on Hacker News.

• by taf2 on 4/10/24, 1:02 AM

  Could this be used as kind of connection proxy to allow for more clients to a single pool of database servers?

• by neximo64 on 4/9/24, 8:58 PM

  Is there anything like this for postgres?

• by hwbunny on 4/10/24, 9:20 PM

  What's the purpose of this idea? Snapshotted mysql server? Who uses that and for what purpose?

• by davgoldin on 4/10/24, 7:05 AM

  Congrats, looks like a lot of hard work!

  Could I swap storage engine with own key value storage e.g. rocksdb or similar?

• by karmakaze on 4/9/24, 8:30 PM

  Compatible has many aspects. I'd be interested in the replication protocols.

• by geenat on 4/9/24, 10:34 PM

  With Vitess likely consolidating its runtimes (vtgate, vtctl, vttablet, etc) into a single unified binary: https://github.com/vitessio/vitess/issues/7471#issuecomment-...

  ... it would be a wild future if Vitess replaced the underlying MySQL engine with this (assuming the performance is good enough for Vitess).

• by ceving on 4/10/24, 12:22 PM

  Why not standard conforming SQL instead of MySQL?

• by kamikaz1k on 4/9/24, 8:32 PM

  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.

  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?_

• by sgammon on 4/9/24, 8:33 PM

  Isn't that........ Vitess?

• by cvalka on 4/9/24, 11:26 PM

  TiDB!

• by amelius on 4/9/24, 9:56 PM

  Performance comparison against the original?