Retention / cleanup strategy for changelog tables in Postgres

[RoderickOxen]

Hi 👋

We’ve been running OpenFGA in production backed by Postgres, and noticed that the changelog table keep growing indefinitely. Over time, this is consuming a significant amount of storage space. (it get's worse for cronjobs which add or remove multiple tuples in a timeframe)

From the docs and schema I understand that:

• changelogHorizonOffset only affects the ReadChanges API (filters out very recent entries to account for replica lag).
• It does not automatically delete or prune old changelog rows.
• There doesn’t seem to be any built-in retention/cleanup mechanism for the changelog.

Questions

1. Is there an official recommendation for handling changelog retention in Postgres?
   For example: should I schedule a periodic SQL DELETE job, use table partitioning, or is there a planned feature for built-in cleanup?

2. What are the risks of deleting rows older than N days from changes / tuple_changes manually?
   (e.g., does OpenFGA rely on having a full changelog history for correctness, or is it only needed for clients consuming ReadChanges?)

3. Would you consider adding:

   • Documentation on how to manage changelog retention in production
   • Or even a configurable TTL / built-in cleanup job?

Motivation

Without some retention strategy, our Postgres instance is accumulating many gigabytes of changelog data, which directly impacts our cloud costs.

For example currently I have:

• Cluster A → ~9 GB of Tuples and ~15 GB of Changelogs
• Cluster B → ~4 GB of Tuples and ~9 GB of Changelogs

(Not great for the monthly cloud payment)

We’d like to keep only ~3 days of changelogs (our consumers don’t need older data), but we want to ensure this won’t break OpenFGA or best practices.

Environment

• Deployment: Kubernetes (Helm chart)
• Datastore: Postgres 13
• SDK: OpenFGA Go SDK v0.7.1

Any input is much appreciated !