kubernetes
Temporal Workflow Resource Calculator
Calculate Kubernetes resource requirements for a self-hosted Temporal workflow engine. Size the History, Matching, Frontend, and Worker services plus the PostgreSQL persistence layer.
Self-Hosting Temporal on Kubernetes
Temporal is a durable execution engine for long-running workflows. Self-hosting on Kubernetes gives you full control but requires understanding how each service scales.
Service Roles
| Service | Role | Scales With |
|---|---|---|
| Frontend | API gateway, gRPC for SDK | Request rate |
| History | Workflow state machine | Active workflow count |
| Matching | Task queue management | Activity worker count |
| Worker | Background maintenance | Workflow throughput |
Active Workflow Count
The key sizing metric is steady-state active workflows — calculated by Little's Law:
active = (workflows_per_day / 1440) × avg_duration_minutesExample: 10,000/day at 5 min average = 34 active at any time.
History Service Sharding
Temporal shards workflow state across 512 default shards (configurable). The History service instance count should be 2–8 for most workloads. Each shard holds a subset of workflow histories in memory.
PostgreSQL Schema
Temporal uses two PostgreSQL databases:
- ›
temporal: workflow execution state, task queues, timers - ›
temporal_visibility: search attributes, workflow list queries
Recommended PostgreSQL setup: connection pooling via PgBouncer (transaction mode), and a read replica for visibility queries.
Helm Chart Deployment
helm repo add temporal https://go.temporal.io/helm-charts
helm install temporal temporal/temporal \
--set server.replicaCount=1 \
--set cassandra.enabled=false \
--set postgresql.enabled=true \
--set elasticsearch.enabled=falseFrequently Asked Questions
What are the Temporal server components?
Temporal server has 4 services: Frontend (API gateway, handles SDK connections), History (workflow state machine, most memory-intensive), Matching (task queue management, connects workers to tasks), and Worker (internal background maintenance). Each can be scaled independently.
Why is the History service the most memory-intensive?
The History service stores the entire event history of every in-flight workflow in memory as a cache. Each workflow generates ~20–100 events (ActivityScheduled, ActivityCompleted, etc.). With 1,000 active workflows × 20 events × 1 KB each = 20 MB minimum — plus the History service shard cache, which can be 2–10× larger.
Should I use PostgreSQL or Cassandra for Temporal persistence?
PostgreSQL for most deployments under 100k workflows/day. It's easier to operate, backup, and restore. Cassandra is designed for Temporal's horizontally sharded architecture at massive scale (millions of executions). Unless you're at that scale, PostgreSQL is the right choice.
Can I run Temporal on a single node Kubernetes cluster?
Yes, for development. Use the temporalio/helm-charts with the 'server' chart and configure all 4 services to run as a single deployment with SQLite or a local PostgreSQL. For production, always separate services and use a managed PostgreSQL (or at minimum a PostgreSQL StatefulSet with persistent storage).
Related Tools
Related Guides
kubernetes
Hetzner vs DigitalOcean for Kubernetes in 2025: An Honest Comparison
Hetzner is 3–5× cheaper than DigitalOcean for equivalent Kubernetes compute. But DO has managed K8s, better global coverage, and a larger app marketplace. Here's when each is the right choice.
kubernetes
Kubernetes Certificate Renewal: What Breaks and How to Fix It
kubeadm certificates expire after 1 year. Here's what actually breaks, how to check expiry, and the exact commands to renew before your cluster goes read-only.
kubernetes
Self-Hosted Kubernetes on Hetzner Cloud: Complete Setup Guide (2025)
A practical guide to running a production-grade HA Kubernetes cluster on Hetzner Cloud using kubeadm, HAProxy, Keepalived, and Longhorn — at a fraction of managed K8s cost.