Call me contrarian but I find the article's approach poor (at least, as it is now).
If one looks at the overall content of the two articles of the series, 70%/80% of the content (or possibly more) is parsing, which is arguably the least interesting, or at least, the most boilerplate, part of a database system.
Regarding goyacc and "usually", I myself was curious about this years ago and asked on Stack Exchange: Do modern languages still use parser generators? [0].
Most of the time, major languages _do_ use hand-written parsers.
Of course it may literally be the case that most other SQL projects in Go do use goyacc. My point is that in general, hand-written parsers are more common in real software than you might think.
[0] https://softwareengineering.stackexchange.com/questions/2502...
Regarding the parsing part, that's interesting. Though the cockroachdb parser is a _great_ lecture about how to add nice error messages with goyacc. (You add a special error token which captures anything after a syntax error, so the parser doesn't break down. At least something around this, haven't yet dived deep into it.)
Though I know Go itself uses a handwritten parser.
Was it because they were the first and people just started using it or is it the best for some reason?
https://www.reddit.com/r/golang/comments/fgwwlx/database_bas...
From my perspective (as the author of OctoSQL): I need a SQL parser. Vitess has a fully fledged MySQL compatible one. I'd probably want to copy the open source vitess one and add the necessary features myself, instead of writing it from scratch. It's just a big endeavor, a few thousand lines of goyacc code and even more Go boilerplate.
I'm not saying everybody is using the same library, because the code has been heavily modified after being copied. A look at the cockroachdb parses suffices to see how much changed it is.
If you look at OctoSQL, there too have been many changes to add stuff like table valued functions.
I'd just like to add for the curious, that usually you'd use goyacc for parsing SQL.
And most serious SQL projects in Go have started with the SQL parser from vitess and adapted it to their use case (which is just funny trivia, but for anything big, I recommend it, did the same for OctoSQL [0]).
[0]: https://github.com/cube2222/octosql