In self-hosted Langfuse, how do you limit how long trace data is retained?

## Two different levers Teams conflate them constantly, so separate them explicitly: - **Retention** decides how long recorded data survives. It is a property of the server, set per project. - **Sampling** decides how much data is recorded at all. It is a property of the client SDK. Only the second reduces ingestion load, ClickHouse write volume and blob storage growth in real time. Only the first bounds how long a leak sits in your store. You usually need both, and for different reasons: sampling for cost and throughput, retention for compliance. ## How retention behaves You configure a retention window in days on the project. The worker container runs the deletion job, and it deletes across the stores that hold the data: rows in the ClickHouse trace, observation and score tables, and the corresponding raw event and media objects in blob storage. Deleting from only one of those would leave the payloads behind, which is why this is a server-side job rather than something you can approximate with a bucket lifecycle rule alone. Because it is asynchronous and batched, express the guarantee honestly: data is removed within the job's cadence after it ages out, not at the instant the clock passes N days. If someone needs a hard contractual deletion deadline, that gap is worth naming rather than glossing over. A practical note for self-hosters: retention deletes reclaim logical space, but reclaiming disk in an OLAP store and in object storage has its own mechanics and lag. Size ClickHouse for steady-state volume at your retention window, plus headroom, rather than assuming the delete job keeps disk flat automatically. ## Sampling, and why trace-level sampling matters The SDK's sample rate is a fraction between 0 and 1, set as `sample_rate` on the client or as `LANGFUSE_SAMPLE_RATE` in the environment. It decides whether a trace is recorded, and the decision applies to the whole trace, not per observation. That is the important behaviour: a half-recorded trace, with the retriever span but not the generation it fed, is worse than no trace, because it misleads you during a debugging session. Sampling whole traces keeps every kept trace complete. The cost of sampling is specific and worth stating: the incident you are called about may be in the 90% you dropped. Teams often run a high sample rate on low-volume, high-stakes flows and a low rate on chatty background traffic, rather than one global number. ## Choosing the window The inputs are not primarily technical: - **Regulatory and contractual obligations.** If a data-protection commitment says customer content is not retained beyond a period, that number is the ceiling, and it is not yours to negotiate. - **Debugging horizon.** How far back do people actually look? For most LLM applications, a bug report arrives within days. Long tails matter mainly for slow-burn quality regressions. - **Evaluation needs.** If you promote production traces into datasets, you need them alive long enough to curate. The usual pattern is a short trace retention window plus datasets, which are configuration-tier data in Postgres and are not swept by trace retention, so a curated example outlives the trace it came from. - **Storage cost.** Real but usually secondary once ClickHouse compression is accounted for. ## Saying it well in an interview The strong answer connects retention to the rest of the data-control story: mask at the client so sensitive content is never sent, self-host so what is sent stays in your network, retain briefly so anything that slipped through has a short life, and sample to keep the volume, and therefore the exposure, proportionate to what you actually debug. Each layer covers a different failure of the others.