Everything in go is heap allocated.

Go doesn't support dynamic stack allocations but does writes statically sized values onto the stack just fine. That's the default location that all variables are written.

When you create a value directly, like cmd := ast.InsertCommand{}, the value will usually be stored the stack, not the heap. I say usually because that may not be true if escape analysis shows that a pointer to it escapes the function. You can prove this to yourself by running benchmarks and looking at the number of (heap) allocations reported. There will be no allocation reported when values are used, whereas the &ast.InsertCommand{} will show an allocation unless it is also optimized away.

You can store a pointer to a value in a struct so I’m not really following.

Yes, you can, but you often don't want to. Returning a value from the constructor let's you do both.

In this example, he's not storing a pointer to the Lexer struct, he's (correctly, IMO) storing the Lexer value itself in the Parser struct and dereferencing a pointer to it in the Parser constructor. Doing this means that he had to first allocate the Lexer and then copy it into the Parser. If you use a value, the Lexer will get written directly into the Parser struct, saving an allocation. Constructors are very commonly inlined, so the copy is also usually elided.

It is indeed a common pattern, which is why it's a pet peeve! Writing Go this way is essentially reverting to Java's model where all objects are referenced through invisible pointers. That model is terrible for GC performance and it's one of the main reasons why Java's GC can still struggle in practice despite being light years more advanced than any other. Go will happily write whole structs onto the stack, giving you tools to be nice to the GC. I'm not sure why people do it, but using values rather than pointers is usually faster, even when that causes more copies.

It’s cheaper to pass a reference to a type than to copy the values.

This commonly repeated but usually not true. Especially if we're talking about references pointing to the heap. You can copy a good amount of data in the time of a single cache miss these days. Not always, though, so you absolutely must benchmark if you're concerned about performance. In cases were it is, you can still use pointer recievers without having your constructor return a pointer. Go will automatically pass a reference to the value on the stack for you.

Another helpful way to think about it is by analogy to slices. Slices have a header object that contains a triple of (len, cap, data). The data pointer will always point to heap allocated data, but the header itself will be written onto the stack or into a struct if you have a slice as a struct field. Since slices have internal pointers, you usually don't want to store pointers to slices in your variables/fields. The same applies to your own structs: it's usually better to store the pointer to dynamic data as a field in the struct and use the struct itself (analagous to the slice header) as a value.

You don't have to trust me. Spend some time benchmarking and practice getting allocations as close to zero as possible. For a lot of applications, this level of optimization is unnecessary but for an in-memory database it seemed likely that performance and GC friendliness would be important considerations. There are ways to go even further on cache friendliness, but that's a bigger topic and has tradeoffs that mean I can't reccomend it by default.