Pre-migration infrastructure checklist for SmithDB on self-hosted LangSmith

Last updated: October 14, 2026

Overview

SmithDB adds three new infrastructure dependencies on top of the existing self-hosted LangSmith stack (Postgres, Redis/Valkey, ClickHouse, optional blob storage): a dedicated PostgreSQL metastore, a dedicated object-storage bucket, and cache storage for the query, ingestion, and compaction-worker components. Before provisioning any of this, confirm your plan against the requirements below. This is the "Before you begin" review the install guide calls for, not a troubleshooting step.

Version requirements

Cloud-support minimums for SmithDB:

  • LangSmith 0.16 with Helm chart 0.16.14 or later on AWS (EKS) and GCP (GKE)

  • LangSmith 0.17 on Azure (AKS)

Upgrading to the current stable release line before enabling SmithDB is recommended but not a strict requirement. Note that the Helm chart version and the packaged application version are not numbered the same, so a chart version alone doesn't tell you the app version it ships. Check the self-hosted changelog to map chart versions to app versions.

Metastore

SmithDB requires a dedicated, empty PostgreSQL 18+ database, separate from the LangSmith operational Postgres database. It must be reachable over private connectivity and configured through a Kubernetes Secret mapped via smithdb.config.metastore.

Object storage

Provision a dedicated bucket, separate from any optional LangSmith blob storage, in the same region as the cluster. Access it via workload identity (or equivalent credentials for your cloud provider).

  • Grant the service account write/admin access on the SmithDB bucket (e.g. roles/storage.objectAdmin on GCP).

  • If you'll migrate historical data, also grant read-only access on the existing blob-storage bucket (e.g. roles/storage.objectViewer on GCP).

  • Do not set independent object-expiration or lifecycle rules on the SmithDB bucket.

Cache storage

Two options are supported for cache storage:

  • Network-attached disk via a per-pod PVC from a StorageClass (default on 0.17).

  • Local SSD, requiring a dedicated node pool (default on 0.16, and recommended for best production cache performance on either version).

Whichever you choose, provision the cache StorageClass/disk for at least 7000 IOPS and 1000 MiB/s per volume.

Sizing

Pick from the tested baseline tiers rather than estimating a custom size:

  • small: 10 ingest / 10 query QPS, metastore sized at 2 vCPU / 16 GiB

  • medium: 100 ingest / 40 query QPS, metastore sized at 4 vCPU / 32 GiB

  • large: 1000 ingest / 100 query QPS, metastore sized at 8 vCPU / 64 GiB

Each tier also has its own per-component Kubernetes resource baselines. These are starting configurations, not throughput ceilings, and you can scale up from there.

Choosing a tier requires representative ingestion and query rate measurements from your own installation's usage/metrics, not estimates from account-level usage data. If you don't have that data yet, start at small and scale up once you can measure actual load.

Rollout

During the staged rollout, keep ClickHouse in place while SmithDB runs dual ingestion, then cut over queries once migration is complete. Any data left unmigrated in ClickHouse isn't reachable through SmithDB-backed queries until it's migrated.

References