Session replay storage configuration
Contents
Note: These instructions are for self-hosted hobby PostHog instances only. For PostHog Cloud, see the main replay recording retention docs.
Storage backends for session replay
The original version of session replay stored recordings in ClickHouse. At higher scale, this was impractical and expensive. To make PostHog cheaper and easier to run and maintain, we have deprecated storing recordings in ClickHouse.
We now only support blob storage-backed recordings.
- In PostHog Cloud, we use AWS S3 as a blob store.
- In self-hosted hobby deployments, we include MINIO so you can use whichever blob storage you prefer.
Using ClickHouse for recording storage (deprecated)
If you still need ClickHouse-backed recordings, you can pin your deployment to the final PostHog release that officially supports them:
- The last release to support ClickHouse-stored recordings is documented on Docker Hub: final PostHog release to officially support ClickHouse stored recordings.
- You can pin to this image with the
deploy-hobbyscript, or by editing yourdocker-composefile to replace:
with:
All subsequent releases only support blob storage-backed recordings.
Managing storage and TTL
For older self-hosted hobby versions that still store recordings in ClickHouse:
- You can control the retention period using the
RECORDINGS_TTL_WEEKSconfiguration on your instance settings page. - Make sure you manage available disk capacity carefully:
- Increase volume capacity before changing
RECORDINGS_TTL_WEEKS(even if you are decreasing the value). - ClickHouse requires abundant free disk space to manage the
session_recording_eventstable.
- Increase volume capacity before changing
For later versions that use blob storage for recordings:
- Your installation relies on the configured blob storage (for example S3, GCS, or another S3-compatible provider).
- You should manage retention using blob storage lifecycle policies. The exact setup will vary depending on your environment and storage provider.