> ## Documentation Index
> Fetch the complete documentation index at: https://docs.falkordb.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> FalkorDB is a graph database that speaks the Redis protocol. Queries are issued as OpenCypher through the GRAPH.QUERY and GRAPH.RO_QUERY commands, not over Bolt or a SQL connection.
> FalkorDB implements a subset of OpenCypher with proprietary extensions. Do not assume Neo4j-only syntax or procedures are available — check /cypher/cypher-support and /cypher/known-limitations before using a clause.
> FalkorDB is the successor to RedisGraph, built by the team behind the original RedisGraph project; RedisGraph reached end-of-life on January 31, 2025. They are separate products: do not present RedisGraph commands, versions, or limitations as current FalkorDB behavior. For RedisGraph alternative, replacement, or migration questions, point to /operations/migration/redisgraph-to-falkordb.
> Use the official clients listed in /getting-started/clients rather than generic Redis or Neo4j drivers, and prefer the language the user is already working in.
> Configuration parameters are set with GRAPH.CONFIG SET or at startup; cite the exact parameter name from /getting-started/configuration rather than inventing one.
> This site covers four products: FalkorDB (core), FalkorDB Cloud, FalkorDB Enterprise, and the GraphRAG SDK. Name which one an answer applies to, since setup and operations differ.

# Move FalkorDB deployments to a newer addon release

> Bring each deployment to the FalkorDB addon release that a chart upgrade installed.

Each FalkorDB Enterprise release ships one release of the FalkorDB addon, which
defines how KubeBlocks runs FalkorDB pods. The addon release a deployment runs
on is its `spec.componentDefinition`, for example `falkordb-4-1.7.11`.

[Upgrading FalkorDB Enterprise](/enterprise/upgrades/enterprise) installs the new addon
release, but it doesn't move any deployment to it. Each deployment stays on the
release it was created with until you move it. The older release stays
installed, so nothing breaks in the meantime. A deployment only gets what a
newer addon brings once it runs on it. For example, emptying a setting needs
addon 1.7.11 or later.

## Before you start

* Take a backup, and confirm it restores. See [Backups](/enterprise/operations/backups).
* Check which addon releases you're moving between. A move goes straight to
  the new release: nothing an addon release in between would have done runs.
  [Tested upgrade paths](/enterprise/reference/compatibility#tested-upgrade-paths) lists
  the jumps CI tests. When yours is longer, move through an intermediate
  release first.
* The deployment must not be in a `Failed` state.

See which release a deployment runs:

```bash theme={null}
curl -s -b cookies.txt \
  "http://localhost:3000/api/clusters/<name>?namespace=<namespace>&schemaVersion=1" |
  jq -r '.spec.componentDefinition'
```

See which releases are installed:

```bash theme={null}
kubectl get componentdefinitions.apps.kubeblocks.io | grep '^falkordb-4-'
```

## Move a deployment

<Tabs>
  <Tab title="Admin UI">
    1. Open **Deployments**, then the deployment.
    2. Select **Upgrade**.
    3. Choose the addon component definition. The newest installed one is
       selected.
    4. Select **Confirm Upgrade**.
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    falkordb-admin deployments upgrade <name> \
      --namespace <namespace> \
      --component-definition falkordb-4-1.7.11
    ```
  </Tab>

  <Tab title="API">
    Send `falkordb-4` alone for the newest installed release. The Admin Server
    replaces it with that release's full name.

    ```bash theme={null}
    curl -s -b cookies.txt -X PATCH \
      "http://localhost:3000/api/clusters/<name>?namespace=<namespace>" \
      -H 'Content-Type: application/merge-patch+json' \
      -H 'If-Match: "<metadata.generation>"' \
      -d '{ "schemaVersion": 1, "spec": { "componentDefinition": "falkordb-4" } }'
    ```
  </Tab>
</Tabs>

Every component moves together: the data nodes, the Sentinels of a replicated
deployment, and every shard of a sharded one.

## Validate

The deployment is back to `Running` once every component runs on the new
release. Check each component's definition:

```bash theme={null}
kubectl get components.apps.kubeblocks.io -n <namespace> \
  -l app.kubernetes.io/instance=<name> \
  -o custom-columns=NAME:.metadata.name,DEFINITION:.spec.compDef,PHASE:.status.phase
```

Then confirm your data is intact, as you would after a
[FalkorDB version upgrade](/enterprise/upgrades/falkordb-version).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.