Skip to main content
Temporal Server uses a database to persist workflow execution state, history, and metadata. This reference describes the schema structure for supported databases.

Supported Databases

  • PostgreSQL (v12+)
  • MySQL (v8+)
  • SQLite (v3) - Development only
  • Cassandra (v3+)
Temporal requires two logical databases:
  1. Temporal Store: Core workflow and shard data
  2. Visibility Store: Search and list operations

Schema Organization

Schemas are located in the source tree:

Temporal Store Schema

Namespaces

namespaces

Stores namespace configuration and metadata. Primary Key: (partition_id, id) Unique Index: name

namespace_metadata

Global namespace metadata. Primary Key: (partition_id)

Shards

shards

Stores history shard metadata and ownership. Primary Key: (shard_id)

Workflow Executions

executions

Stores mutable state for workflow executions. Primary Key: (shard_id, namespace_id, workflow_id, run_id)

current_executions

Tracks the current (latest) run for each workflow ID. Primary Key: (shard_id, namespace_id, workflow_id)

current_chasm_executions

Tracks current Chasm (state machine) executions. Primary Key: (shard_id, namespace_id, business_id, archetype_id)

History Events

history_node

Stores history events in a tree structure. Primary Key: (shard_id, tree_id, branch_id, node_id, txn_id)

history_tree

Stores metadata about history branches. Primary Key: (shard_id, tree_id, branch_id)

Tasks

history_immediate_tasks

Immediate tasks (transfer, visibility) for workflow execution. Primary Key: (shard_id, category_id, task_id)

history_scheduled_tasks

Scheduled tasks (timers, delayed tasks). Primary Key: (shard_id, category_id, visibility_timestamp, task_id)

Task Queues

tasks_v2

Stores workflow and activity tasks with fairness scheduling. Primary Key: (range_hash, task_queue_id, pass, task_id)

task_queues_v2

Task queue metadata and state. Primary Key: (range_hash, task_queue_id)

task_queue_user_data

User-defined task queue data including versioning. Primary Key: (namespace_id, task_queue_name)

build_id_to_task_queue

Maps worker build IDs to task queues. Primary Key: (namespace_id, build_id, task_queue_name)

Cluster Management

cluster_metadata_info

Stores cluster configuration for multi-cluster setups. Primary Key: (metadata_partition, cluster_name)

cluster_membership

Tracks cluster members and their roles. Primary Key: (membership_partition, host_id) Indexes:
  • (role, host_id)
  • (role, last_heartbeat)
  • (rpc_address, role)
  • (last_heartbeat)
  • (record_expiry)

Queues

queues

Named queue metadata. Primary Key: (queue_type, queue_name)

queue_messages

Messages in named queues. Primary Key: (queue_type, queue_name, queue_partition, message_id)

Nexus Endpoints

nexus_endpoints

Stores Nexus endpoint configurations. Primary Key: (id)

nexus_endpoints_partition_status

Tracks version of nexus_endpoints table. Primary Key: (id) Constraint: id = 0 (single row table)

Visibility Store Schema

executions_visibility

Main visibility table for workflow search. Primary Key: (namespace_id, run_id) Indexes:
  • (namespace_id, close_time, status)
  • (namespace_id, start_time, status)
  • (namespace_id, workflow_type_name, close_time)
  • Additional indexes on search attributes

Schema Versioning

Temporal uses versioned schema migrations:
  • Base schema: schema.sql
  • Migrations: versioned/vX.Y/*.sql
Example:

Setup and Migration

Initial Setup

Upgrade Schema

Best Practices

  1. Separate Databases: Use separate physical databases for temporal and visibility stores
  2. Connection Pooling: Configure appropriate connection pool sizes
  3. Indexes: Monitor slow queries and add indexes as needed
  4. Partitioning: Consider table partitioning for very large deployments
  5. Backups: Regular backups are essential - test restore procedures
  6. Retention: Configure appropriate retention policies
  7. Monitoring: Monitor database metrics (CPU, IOPS, connections)

See Also