Short answer: don’t truncate just event_resources. If you remove only that table, you’ll orphan rows in events (and related tables), break event queries, and the UI timeline. If you want to purge event data, truncate the whole events storage set together or use the built‑in retention service. Details and safer options: What event_resources is used for - It’s the normalized lookup table for resources referenced by each event. Events point to one or more rows in event_resources. - Truncating event_resources alone will break foreign keys and event queries (and can block inserts) unless you also remove dependent rows in events and any relation tables. Safer ways to reclaim space 1) Use Prefect’s event retention (recommended) - Ensure the Event Persister is enabled and shorten retention so it prunes in batches until caught up. - PREFECT_SERVER_EVENTS_RETENTION_PERIOD (default P7D). Set to something small temporarily (e.g., P1D) and restart the server. - PREFECT_SERVER_SERVICES_EVENT_PERSISTER_ENABLED=true - Optionally increase delete batch size: - PREFECT_SERVER_SERVICES_EVENT_PERSISTER_BATCH_SIZE_DELETE=100000 (tune to your DB) - If you want to stop new growth while it prunes, temporarily disable event ingestion: - PREFECT_SERVER_SERVICES_EVENT_LOGGER_ENABLED=false - Docs: - Database maintenance - Settings: retention_period - Event Persister service 2) Hard reset event data (if you truly don’t need the timeline or any event history) - Stop Prefect server services that write/read events. - Truncate the entire event storage set together so there are no orphaned references. For example:

BEGIN;
  -- Order matters only if you do not use CASCADE; using CASCADE is simplest:
  TRUNCATE TABLE events, event_resources, event_related_resources RESTART IDENTITY CASCADE;
  COMMIT;

Notes: - Table names can vary by version/migrations; inspect your schema first and include any relation tables that reference events or event_resources. - This will erase all event history. Flow runs, task runs, and deployments are stored in separate tables and will continue to work. - After truncation, you can keep events off if you don’t use them:

PREFECT_SERVER_SERVICES_EVENT_LOGGER_ENABLED=false

- Take a DB backup before doing this. 3) If vacuum is the blocker - After pruning or truncating, use pg_repack to reclaim space online if VACUUM FULL is too disruptive. - See Prefect DB maintenance for guidance and general tips. Given you don’t use automations - You can safely delete all events if you’re okay losing the timeline and event history; automations won’t be impacted because you aren’t using them. Do not truncate just event_resources—wipe the event tables together. - If you’d prefer to keep a small rolling history, enable the persister and drop retention to a day or two until the tables shrink, then raise it back. Happy to tailor exact SQL and environment settings if you can share: - How you’re running Prefect Server (Docker Compose, Helm, etc.) - Your Postgres version - The current size/row counts of events/event_resources - Whether you’d like to disable events permanently or keep a short retention window