Statestore

The statestore is the durable substrate the control plane writes to when a feature needs state that outlives a single request or a single pod.

It exposes three capabilities behind one interface — a key/value store, an append-only event log, and a visibility-timeout queue — served by a pluggable driver. Fission itself never deploys a database product. For development, use the bundled embedded driver. For production, point the external driver at a database you already run.

The statestore is what makes Fission’s newer durable features possible. Starting with Fission v1.27.0, several subsystems build on it:

• Durable Workflows record every step of a run in the event log, so a run survives a controller restart and resumes exactly where it stopped.
• Asynchronous invocation enqueues each fire-and-forget call on the queue and delivers it in the background with retries and a dead-letter queue.
• Function state gives a function a private keyspace of durable key/value entries — counters, sessions, carts, agent memory — with no external Redis or database.
• Eventing uses the event log and queue as its zero-broker transport.

The statestore is off by default. A feature that needs it tells you to enable it.

flowchart TB
  wf["Workflow Engine"]:::fission
  async["Async Router / Worker"]:::fission
  evt["Eventing"]:::fission
  subgraph ss["Statestore"]
    kv["Key/Value"]:::store
    log["Event Log (append-only, CAS)"]:::store
    queue["Queue (visibility timeout)"]:::store
  end
  driver["Driver"]:::fission
  embedded["SQLite on a PVC<br/>(embedded)"]:::pod
  external["Postgres via DSN Secret<br/>(external)"]:::pod

  wf --> log
  async --> queue
  evt --> log
  evt --> queue
  kv --> driver
  log --> driver
  queue --> driver
  driver -->|"embedded"| embedded
  driver -->|"external"| external

  classDef fission fill:#e8f0fe,stroke:#2d70de,color:#1f2a43
  classDef pod fill:#e6f7f1,stroke:#11a37f,color:#1f2a43,stroke-dasharray:5 3
  classDef store fill:#fff7e0,stroke:#dba514,color:#1f2a43,stroke-dasharray:5 3

Embedded vs external

The driver is chosen with statestore.mode. The two modes differ only in where the state lives. The interface the features use is identical.

KEDA autoscaling for asynchronous invocation requires statestore.mode=external. The KEDA PostgreSQL scaler reads the backlog directly from the database and cannot reach the embedded SQLite file inside the pod.

Enable the statestore

The statestore is off by default. Enable it and pick a mode with Helm values.

Embedded (SQLite on a PVC — development):

helm upgrade --install fission fission-charts/fission-all \
  --namespace fission \
  --set statestore.enabled=true \
  --set statestore.mode=embedded \
  --set statestore.embedded.size=1Gi

External (Postgres — production): create a Secret holding the DSN, then point the chart at it:

kubectl create secret generic statestore-postgres \
  --namespace fission \
  --from-literal=dsn='postgres://user:password@postgres.db.svc:5432/fission?sslmode=require'

helm upgrade --install fission fission-charts/fission-all \
  --namespace fission \
  --set statestore.enabled=true \
  --set statestore.mode=external

Related

• Durable Workflows — multi-step orchestration recorded in the event log.
• Asynchronous Invocation — fire-and-forget calls delivered from the queue.
• Architecture overview — how the statestore sits alongside the other components.