> Full SurrealDB documentation index: https://surrealdb.com/docs/llms.txt

# 3.2 to 3.3

What changes on disk and in behaviour when a 3.2 installation moves to 3.3, and which steps are automatic.

`3.3` is a minor release, so a `3.2` datastore opens on `3.3` without an export and import. This page covers the two migrations that run against stored data, and one default that changes. For everything else, see the [release notes](/releases) and the [general upgrade guide](/docs/build/migrating/from-old-surrealdb-versions/overview.md).

Upgrade the binary with [`surreal upgrade`](/docs/reference/cli/surrealdb-cli/commands/upgrade.md) as usual.

## Full-text, HNSW and DiskANN indexes keep their 3.2 layout

`3.3` serves full-text, HNSW and DiskANN indexes written by `3.2` on the layout they already have, so an upgrade needs no index work to return correct results. The new layout is opt-in through [`REBUILD INDEX`](/docs/reference/query-language/statements/rebuild.md), which you can run when it suits the workload rather than as part of the upgrade.

The cache for HNSW and DiskANN is scoped by stored format version, so readers before and after a rebuild stay isolated from each other.

> [!NOTE]
> Beta releases `3.3.0-beta.1` through `3.3.0-beta.3` rejected these indexes at query time and required an immediate rebuild. A datastore upgraded through one of those betas is unaffected once it reaches `3.3.0`, since the layout was preserved rather than converted.

## Silo module definitions are rekeyed

A module definition stored by `3.2.4` or earlier is keyed by a derivation that changed in `3.3.0`. Upgrading to `3.3.0` runs a migration that rekeys those definitions to the name every statement derives, which is what keeps them reachable.

The migration runs once, on first start against the older data, and needs no flag.

> [!IMPORTANT]
> The migration reached its final form in `3.3.0-beta.4`. On `3.3.0-beta.3` and earlier it was registered against a later version than the running server, so it never ran and the affected definitions stayed unreachable. Upgrading straight to `3.3.0` runs it.

## ISO GQL is on by default

GQL no longer needs an experimental capability. On `3.2.x` it was reached with `--allow-experimental gql`; from `3.3.0` it is available without one, and the `gql` experimental tag is still accepted but does nothing.

A deployment that served no GQL on `3.2.x` by leaving the experimental tag unset now serves it, so closing it is an explicit step. The executor has four entry surfaces with separate switches, listed under [GQL entry surfaces](/docs/learn/security/authorization/capabilities.md#gql-entry-surfaces).

The [`eval::gql()`](/docs/reference/query-language/functions/database-functions/eval.md) function is the exception: eval stays denied for every subject by default, including under `--allow-all`.