# Temporal v1.31.0

- Product: Temporal (https://whatsnew.fyi/product/temporal)
- Vendor: Temporal Technologies
- Date: 2026-04-29
- Version: v1.31.0
- Original notes: https://github.com/temporalio/temporal/releases/tag/v1.31.0
- Permalink: https://whatsnew.fyi/product/temporal/releases/v1.31.0

What's New is an index, not a publisher: every entry below links to the vendor's own release notes, which are the authoritative source. Entries are labelled where they are hand-curated sample data, pre-releases, or drawn from a secondary source such as a developer blog.

Reuse: the summaries, labels and curation here are © What's New. Quote freely with attribution and a link back; wholesale republication of the corpus is not permitted — terms: https://whatsnew.fyi/terms. The vendors' own release notes remain their publishers'.

---

- **added** — Add support for Serverless Workers on AWS Lambda with automatic invocation, scaling, and shutdown via the new Worker Controller Instance (WCI) component
- **added** — Add immutable Principal field to workflow history events for server-computed, trustworthy attribution of actions
- **added** — Add passwordCommand config option for SQL datastores to enable IAM-based authentication for cloud-managed databases
- **added** — Add new current_chasm_executions table in core schema to support CHASM separate archetype ID spaces
- **changed** — Update core schema to MySQL v1.19, PostgreSQL v1.19, and SQLite v1.11
- **changed** — Update visibility schema to MySQL v1.14, PostgreSQL v1.14, and Elasticsearch v14 with new TemporalExternalPayloadSizeBytes and TemporalExternalPayloadCount fields
- **changed** — Overhaul Nexus error model to enable handlers and operations to convey their own messages
- **removed** — Remove Nexus feature flag and enable Nexus by default

#### Schema changes

> [!WARNING]
> Before upgrading your Temporal Cluster to `v1.31.0`, you must upgrade core and visibility schema to the following:

- Core:
  - MySQL schema `v1.19`
  - PostgreSQL schema `v1.19`
  - SQLite schema `v1.11`
- Visibility:
  - Elasticsearch schema `v14`
  - MySQL schema `v1.14`
  - PostgreSQL schema `v1.14`

Please see our [upgrade documentation](https://docs.temporal.io/self-hosted-guide/upgrade-server) for the necessary steps to upgrade your schemas.

Please see CHASM section below for more information about the core schema change if you have a custom persistence implementation.

###### Temporal database schema details

**MySQL `v1.19`, PostgreSQL `v1.19`, SQLite `v1.11`** — adds a new `current_chasm_executions` table for CHASM separate archetype ID spaces:

```sql
CREATE TABLE current_chasm_executions(
  shard_id, namespace_id, business_id, archetype_id,
  run_id, create_request_id, state, status, start_version,
  start_time, last_write_version, data, data_encoding,
  PRIMARY KEY (shard_id, namespace_id, business_id, archetype_id)
);
```

###### Visibility schema details

**MySQL `v1.14`, PostgreSQL `v1.14`** — adds `TemporalExternalPayloadSizeBytes` and `TemporalExternalPayloadCount` as generated columns with indexes.

**Elasticsearch `v14`** — new index template version with `TemporalExternalPayloadSizeBytes` and `TemporalExternalPayloadCount` fields.

###### CHASM persistence schema change (custom persistence implementations only)

CHASM framework now supports separate `businessID` spaces for different archetypes and includes corresponding schema changes for SQL core databases. This is achieved by storing multiple current mutable state records in the database, one for each archetype.

If you maintain a custom persistence implementation (Cassandra-based or SQL-based), you must update it to support separate `businessID` spaces as well. All current mutable state related persistence requests now include a new `ArchetypeID` field, and your persistence implementation should read or update the current mutable state record for that archetype. Please refer to https://github.com/temporalio/temporal/pull/8907 (Cassandra) or https://github.com/temporalio/temporal/pull/8915 (SQL) for sample changes.

---
#### Serverless Workers (pre release)

This version of Temporal Server adds support for Serverless Workers. This feature allows Temporal Workers to run on serverless compute platforms - with AWS Lambda being the first supported platform. Temporal can automatically invoke, scale, and gracefully shut down (scaling to zero, if appropriate) Temporal Workers on your behalf based on workload volume and metrics. See the [Serverless Workers documentation](https://docs.temporal.io/serverless-workers) to get started.

Invocation is handled by a new server component, the Worker Controller Instance (WCI), which monitors Task Queues and dispatches invocations to a configured compute provider. WCI is disabled by default and must be enabled via the `workercontroller.enabled` dynamic config key. See [Enable the Worker Controller Instance](https://docs.temporal.io/production-deployment/worker-deployments/serverless-workers/self-hosted-setup#enable-worker-controller) for complete configuration instructions.

Self-hosted setup requires network reachability from the Lambda execution environment to the Temporal frontend, AWS credentials for the server to assume customer IAM roles, and an IAM role in the target account granting `lambda:GetFunction` and `lambda:InvokeFunction`. See the [self-hosted setup guide](https://docs.temporal.io/production-deployment/worker-deployments/serverless-workers/self-hosted-setup) for full setup instructions.

#### Principal Attribution

Adds a server-computed, immutable `Principal` field to workflow history events, providing trustworthy attribution for "who did this?". Unlike the client-supplied `identity` field, `Principal` is derived fr

_[Truncated at 4000 characters — full notes: https://github.com/temporalio/temporal/releases/tag/v1.31.0]_