Does SurrealDB 2.0 preserve the SELECT syntax used in version 1.x?

Short answer

No — you should not assume your 1.x SELECT statements run unchanged on SurrealDB 2.0. The 2.0 release is a major version that deliberately revised parts of SurrealQL, and the clauses you name — FETCH, SPLIT, and GROUP BY — are exactly the areas flagged as breaking. There is no published compatibility matrix or automated migration tool that certifies SELECT stability across the 1.x → 2.0 boundary, so per-query verification is the only safe path.

What is confirmed vs. what is likely

Confirmed facts (from the 2.0 release notes and migration guidance):

• SurrealDB 2.0 is a major release with documented breaking changes to SurrealQL, and the release notes include migration examples for affected syntax.
• The SPLIT keyword form was replaced by a SPLIT() function. Queries written as SELECT * FROM t SPLIT field need rewriting to the function form, e.g. SELECT * FROM SPLIT(field)-style expressions.
• GROUP BY semantics were tightened: wildcard grouping (SELECT * GROUP BY *) is no longer supported, and explicit grouping keys are required.

Likely, but verify against your exact 2.x minor version:

• SELECT … FETCH changed behavior — it now operates over a collection of objects rather than returning the scalar-style results some 1.x queries relied on. Queries may still parse but return a different result shape, which is the most dangerous failure mode because nothing errors out.
• Some clauses that look unchanged may behave subtly differently due to engine changes. Patch releases within 2.x may also have adjusted details, so pin and test the exact version you will deploy.

How to verify before upgrading

1. Stand up two instances side by side: your current 1.x version and the target 2.x version, with identical schema and seeded data.
2. Export your real query workload (application code, scheduled jobs, dashboard queries) rather than inventing test queries — edge cases live in production SQL, not in docs examples.
3. Run each SELECT against both instances and diff results, error messages, and result shapes. Pay special attention to anything using FETCH, SPLIT, GROUP BY, or wildcard projections.
4. For failures, rewrite using the 2.0 migration examples (e.g., SPLIT keyword → SPLIT() function, implicit grouping → explicit keys) and re-diff.

# Example: run the same query file against both versions
surreal sql --endpoint http://localhost:8000 --ns app --db app < queries.surql > out-1x.txt
surreal sql --endpoint http://localhost:8001 --ns app --db app < queries.surql > out-2x.txt
diff out-1x.txt out-2x.txt

Bottom line

Treat the 1.x → 2.0 upgrade as a query migration, not a drop-in version bump. The breaking changes are documented in the release notes, but since no compatibility suite guarantees coverage of your specific queries, a regression diff against real workloads is the only reliable confirmation. If you can share one failing query and the exact 2.x version you tested against, the rewrite for that case can be pinned down precisely.