# Backends

As explained in the Overview, when Kuma (kuma-cp) is up and running it needs to store data somewhere. The data will include the state, the policies configured, the data-planes status, and so on.

Kuma supports a few different backends that we can use when running kuma-cp. You can configure the backend storage by setting the KUMA_STORE_TYPE environment variable when running the control plane.

This information has been documented for clarity, but when following the installation instructions these settings will be automatically configured.

Following backends are available

# Memory

Kuma stores all the state in-memory. This means that restarting Kuma will delete all the data. Only recommend when playing with Kuma locally. For example:

$ KUMA_STORE_TYPE=memory kuma-cp run
1

This is the default memory store if KUMA_STORE_TYPE is not being specified.

# Kubernetes

Kuma stores all the state in the underlying Kubernetes cluster. Used when running in Kubernetes mode. For example:

$ KUMA_STORE_TYPE=kubernetes kuma-cp run
1

# Postgres

Kuma stores all the state in a PostgreSQL database. Used when running in Universal mode. You can also use a remote PostgreSQL database offered by any cloud vendor. For example:

$ KUMA_STORE_TYPE=postgres \
  KUMA_STORE_POSTGRES_HOST=localhost \
  KUMA_STORE_POSTGRES_PORT=5432 \
  KUMA_STORE_POSTGRES_USER=kuma-user \
  KUMA_STORE_POSTGRES_PASSWORD=kuma-password \
  KUMA_STORE_POSTGRES_DB_NAME=kuma \
  kuma-cp run
1
2
3
4
5
6
7

# Migrations

To provide easy upgrades between Kuma versions there is a migration system of Postgres DB schema.

When upgrading to new version of Kuma, run kuma-cp migrate up so the new schema is applied.

$ KUMA_STORE_TYPE=postgres \
  KUMA_STORE_POSTGRES_HOST=localhost \
  KUMA_STORE_POSTGRES_PORT=5432 \
  KUMA_STORE_POSTGRES_USER=kuma-user \
  KUMA_STORE_POSTGRES_PASSWORD=kuma-password \
  KUMA_STORE_POSTGRES_DB_NAME=kuma \
  kuma-cp migrate up
1
2
3
4
5
6
7

Kuma CP at start will check if the current DB schema is compatible with the version of Kuma you are trying to run. Information about current newest migration is stored in schema_migration table.