Event Storage & Retention
The Hub persists only finalized outgoing events — the same events exposed externally by the GraphQL API. Raw or intermediate internal events from VPP, CIGS, CBS, or MCT are never stored. Persistence is handled by the DbWorker Service, a background service with no external interface.
What is stored
| Table | Written on | Contents |
|---|---|---|
identification_events | identification.* topics | Result, clearance, member context snapshot, face crop, full frame |
identities | identity.created, identity.updated | Identity ID, first/last seen, linked identification if available |
identity_faces | identity.updated | Individual face detection associated with an identity |
zone_events | zone.* topics | Event type, unit, person count, occupancy context, timestamp |
Face crops and full frames are stored directly in PostgreSQL; VPP management entities (cameras, watchlists, members) are never stored locally — they are proxied from VPP on demand.
Retention modes
Storage behavior is configured per deployment:
| Mode | Behaviour |
|---|---|
STORAGE_ENABLED=false | No data written at all — recommended for GDPR-sensitive deployments where event data must not be stored at rest |
STORAGE_ENABLED=true | Events and images persisted; a scheduled retention job removes expired records |
Retention periods apply independently per data type and are configurable: event records (identification, identity, zone) default to 48 hours, image data (face crops, full frames) to 24 hours.
STORAGE_ENABLED=true
RETENTION_TTL_EVENTS_HOURS=48
RETENTION_TTL_IMAGES_HOURS=24
RETENTION_JOB_INTERVAL_MINUTES=30
Querying
Stored events are queryable through the GraphQL API by event type, time range, unit ID, correlation ID, and source system — paginated, in chronological order. This short rolling window serves audit, retrieval, and GUI state-restore needs without long-term data accumulation.
Related pages
- Event Catalog — which event types exist
- DbWorker Service — the service enforcing persistence an