Configure SmithDB for scale

For non-SmithDB LangSmith services, see Configure LangSmith for scale.

Use these tested tiers as starting configurations for SmithDB. Connect SmithDB to your monitoring stack before you tune capacity, so you can observe the effect of each change. See Configure SmithDB observability.

Choose and scale a tier

The tiers are not throughput limits or prescribed configurations. CPU, memory, and cache size are per replica. Cache size is the volume each replica gets: the claim size on a network-attached disk, or the emptyDir limit on local SSD. Choose the tier whose tested ingestion and query rates most closely match or exceed your expected steady-state load. To estimate your current trace volume, open Settings > Usage in LangSmith. See Granular billable usage. If you cannot measure your load, start at small and scale up. Under-sizing shows up as slower ingestion and queries rather than data loss. Apply the per-replica resources and starting replica counts from the selected tier. If the workload later outgrows that starting point, you can scale SmithDB compute horizontally.

SmithDB query, ingestion, and compaction-worker HPAs are enabled by default. They require Kubernetes Metrics Server or another metrics.k8s.io provider. Verify availability with kubectl get --raw /apis/metrics.k8s.io/v1beta1.

Scale with KEDA instead

KEDA scaling for SmithDB compaction workers requires Helm chart 0.17.0 or later.

SmithDB compaction workers can scale on queue depth through KEDA rather than the CPU-based HPA. This suits bursty compaction backlogs, where queue depth rises before CPU does. LangSmith uses the same KEDA installation for its own queues; see KEDA autoscaling for LangSmith queues to install and configure it. Enable the KEDA scaler for compaction workers:

smithdb:
  compactionWorker:
    autoscaling:
      hpa:
        enabled: false
      keda:
        enabled: true

Use either the HPA or KEDA for a component, not both.

Baseline tiers

Component	Small 10 ingest / 10 query QPS	Medium 100 ingest / 40 query QPS	Large 1000 ingest / 100 query QPS
Ingestion	1 replica 4 CPU 8 Gi memory 100 Gi cache	1 replica 16 CPU 32 Gi memory 100 Gi cache	2 replicas 56 CPU 150 Gi memory 1000 Gi cache
Query	1 replica 4 CPU 8 Gi memory 200 Gi cache	1 replica 28 CPU 48 Gi memory 200 Gi cache	4 replicas 28 CPU 50 Gi memory 1000 Gi cache
Compaction	1 replica 2 CPU 4 Gi memory	1 replica 4 CPU 8 Gi memory	1 replica 8 CPU 16 Gi memory
Compaction worker	1 replica 8 CPU 16 Gi memory 100 Gi cache	1 replica 16 CPU 32 Gi memory 100 Gi cache	4 replicas 28 CPU 50 Gi memory 300 Gi cache
Cluster manager	1 replica 250m CPU 256 Mi memory	1 replica 250m CPU 256 Mi memory	1 replica 2 CPU 2 Gi memory

Configure resources with Helm

The chart defaults to small. Select small, medium, or large:

smithdb:
  resourceTier: medium

On LangSmith 0.17 the tier’s cache size becomes the generated claim’s capacity. On 0.16 it is the ephemeral-storage request and limit, which also sizes the generated emptyDir. Replica counts and autoscaling are configured separately. An explicit component resources block replaces the tier’s CPU and memory. On 0.17 it does not change the cache size; pick a different tier or override deployment.volumes for that. For local SSD values, see Cache storage. See SmithDB resource tiers for current values and chart details.

Example explicit resource configuration

This example overrides the query component at medium-tier sizes.

LangSmith 0.17
LangSmith 0.16

The cache claim stays at the tier size. These values request no node storage.

smithdb:
  resourceTier: medium
  query:
    deployment:
      resources:
        requests:
          cpu: "28"
          memory: "48Gi"
        limits:
          cpu: "28"
          memory: "48Gi"

The storage limit also sizes the default emptyDir.

smithdb:
  resourceTier: medium
  query:
    deployment:
      resources:
        requests:
          cpu: "28"
          memory: "48Gi"
          ephemeral-storage: "200Gi"
        limits:
          cpu: "28"
          memory: "48Gi"
          ephemeral-storage: "200Gi"

Metastore capacity

The baseline tiers cover SmithDB Kubernetes workloads only. They do not include the PostgreSQL metastore. Use these starting points for a dedicated metastore:

Tier	vCPU	Memory
Small	2	16 GiB
Medium	4	32 GiB
Large	8	64 GiB

Choose the nearest supported PostgreSQL instance shape from your provider and monitor database resource use and transaction latency during rollout.

Connect these docs to your agent of choice via MCP for real-time answers.

Edit this page on GitHub or file an issue.

Get started by cloud provider

Deploy with Terraform

Setup guides

Configuration

Connect external services

Platform auth & access control

SmithDB

Self-hosted observability

Hybrid

Scripts

Reference

Choose and scale a tier

Scale with KEDA instead

Baseline tiers

Configure resources with Helm

Metastore capacity

​Choose and scale a tier

​Scale with KEDA instead

​Baseline tiers

​Configure resources with Helm

​Metastore capacity

Choose and scale a tier

Scale with KEDA instead

Baseline tiers

Configure resources with Helm

Metastore capacity