StaticdeployDeploys the prune() Postgres function into the target schema.
Idempotent — uses CREATE OR REPLACE and can be called repeatedly.
The function is automatically deployed when DBA.prune is called, but this method is exposed for explicit control (e.g., CI/CD migration scripts that provision database objects before the application starts).
Postgres provider configuration
Application identifier (schema name)
StaticprunePrunes expired data and/or strips execution artifacts from completed jobs. Each operation is independently controlled, so callers can target a single table per cron schedule.
Operations (each enabled individually):
adata,
hmark, jmark, status, other) from completed jobs,
retaining only jdata and udataPrune configuration
Counts of deleted/stripped rows
import { Client as Postgres } from 'pg';
import { DBA } from '@hotmeshio/hotmesh';
// Strip attributes only — keep all jobs and streams
await DBA.prune({
appId: 'myapp',
connection: {
class: Postgres,
options: { connectionString: 'postgresql://usr:pwd@localhost:5432/db' }
},
jobs: false,
streams: false,
attributes: true,
});
Database maintenance operations for HotMesh's Postgres backend.
HotMesh uses soft-delete patterns: expired jobs and stream messages retain their rows with
expired_atset but are never physically removed during normal operation. Over time, three tables accumulate dead rows:{appId}.jobsexpired_atset{appId}.jobs_attributesadata,hmark,jmark,status,other) that are only needed during workflow execution{appId}.streamsexpired_atsetThe
DBAservice addresses this with two methods:Independent cron schedules (TypeScript)
Each table can be targeted independently, allowing different retention windows and schedules:
Example
Direct SQL (schedulable via pg_cron)
The underlying Postgres function can be called directly, without the TypeScript SDK. Schedule it via
pg_cron,crontab, or any SQL client: