ClickHouse to SmithDB migration: config behavior differences to know
Last updated: October 29, 2026
Overview
Migrating self-hosted LangSmith from ClickHouse to SmithDB changes how several pieces of the chart behave. None of the items below are misconfigurations: they are differences in how SmithDB is designed versus ClickHouse. This article covers the behavior for the metastore database, blob storage, TTL/retention, custom CA trust, and disk usage.
Postgres metastore
SmithDB does not have a Postgres schema setting, and it does not share or inherit the existing LangSmith application database. It needs its own dedicated, empty Postgres database, configured through the smithdb.config.metastore secret keys. SmithDB initializes its own schema in that database.
The metastore is an indexing layer only: it stores file/compaction/TTL/feedback metadata. Trace payloads themselves are never stored in the metastore; those live in SmithDB's object storage.
Blob storage is still required
SmithDB's durable object store (smithdb.config.objectStore) is separate from LangSmith's existing blob storage (config.blobStorage). Keep config.blobStorage and its bucket configured after ClickHouse is retired. It's still used:
As the source read during migration of historical traces.
As the ingestion landing point for large payloads before SmithDB copies them into its own bucket.
As the permanent store for trace attachments. SmithDB only keeps a link to attachments, not the attachment bytes.
TTL and retention carry over
config.ttl.enabled and config.ttl.ttl_period_seconds continue to apply after the move to SmithDB. These settings are passed through to the SmithDB query, compaction, and compaction-worker services, as well as to LangSmith itself, so existing retention configuration doesn't need to change. ClickHouse-specific cleanup jobs don't carry over (they're no longer relevant), but the retention configuration itself is unaffected.
Don't apply object-expiration lifecycle rules directly on the SmithDB object storage bucket. SmithDB manages object deletion itself based on TTL, and an external lifecycle rule expiring live objects can make data unavailable.
Custom CA is not wired into SmithDB pods
This is a real gap, not an oversight on your end. config.customCa drives the CA secret volume mount and SSL_CERT_FILE wiring used by LangSmith's common pod environment and several other components. SmithDB's pods build their own component environment and do not pick up this wiring: they get no CA volume mount and no SSL_CERT_FILE.
If any SmithDB connection needs a private CA, for example the metastore Postgres connection configured with useSsl: true, that trust is not automatically available the way it is for the rest of LangSmith. Treat this as something to request/handle separately rather than assuming config.customCa covers it. (SmithDB doesn't connect to Redis, so a Redis-specific CA is never needed by SmithDB.)
Disk usage: cache, not durable storage
ClickHouse used a static volume where a full disk could cause data loss or failure. SmithDB's per-pod volumes (on the query, ingestion, and compaction worker pods) work differently: they're an evictable cache, not the durable store. The actual trace data lives in SmithDB's object storage bucket.
When the cache reaches its configured size, the query service evicts least-used data to make room rather than failing or losing data. The cache volumes do not auto-expand when full, so size them for your working set rather than treating them as capacity planning for total trace volume. The default `small` tier requests 200Gi for the query pod and 100Gi each for the ingestion and compaction worker pods.