Not super sure if it follows any of them, but it might be ANSI 2011, since Cloud Spanner SQL is described as "ANSI 2011 with extensions", and I would expect that to be a strict subset of ZetaSQL.

For some more context, ZetaSQL is the thing we've standardized our internal systems on, aka F1, Dremel/BigQuery, Spanner (and there's a few others). The F1 Query paper makes a light reference to this in S7.2 http://www.vldb.org/pvldb/vol11/p1835-samwel.pdf.

For me, the most valuable feature of it has been that protos are an explicitly defined data type, since we use protos for pretty much everything. Docs: https://github.com/google/zetasql/blob/master/docs/one-pager...

EDIT: BigQuery SQL is described as "compliant with the SQL 2011 standard and has extensions", and I would also expect that to be a strict subset of ZetaSQL.

Google has it's own internal SQL dialect. It's the same that is also used in Cloud Spanner. I think it's mostly standard complaint, but less feature complete than the standard sql dialects.

I’m pretty sure it wouldn’t follow any; I can’t imagine any significant benefit (if you’re not chasing strict compatibility, general SQL should take you more than far enough on the beginner-friendly front) and significant benefit from doing a custom SQL

A benefit of following an established standard is that one can use this not just to write a new engine but also to build internal tooling (static analysis, linters, IDE tools etc.) for an existing one (e.g. MySQL).

What significant benefit

Things like late row lookups in mysql that are not an issue in postgres https://explainextended.com/2011/02/11/late-row-lookups-inno...

aren't both executions (mysqls' and postgresqls') acceptable from an SQL point of view?

I don't think the SQL standard mandates how the DBMS executes the query. In fact, I seem to remember that was on of the purposes of having an high level language.