Postgres stores

The core runtime and most durable feature modules have Postgres implementations. They can share one postgres client and one database while keeping separate store contracts.

import postgres from 'postgres'
import { postgresStore } from '@noir-agent/agent/store/postgres'
import { postgresScheduleStore } from '@noir-agent/agent/scheduler'

const sql = postgres(process.env.DATABASE_URL!)
const database = postgresStore({ sql })
const schedules = postgresScheduleStore({ sql })

await database.migrate()
await schedules.migrate()

Passing a connection string directly is also supported:

const database = postgresStore(process.env.DATABASE_URL!)
await database.migrate()

Lifecycle

When a store creates its own client, its close method can close it. When stores share an application client, close the client once from application lifecycle after the agent stops. A small persistence capability is a useful place for ordered migrations and one-time cleanup.

Feature stores

Postgres implementations exist for schedules, tasks, sandboxes, connections, secrets, traces, usage, snapshots, groups, entities, browser state, API keys, quality, versioning, steering, escalation, and other stateful modules. Import only the feature subpaths your agent uses.

Deployment

Migrations are explicit and idempotent, but production applications should still run them as a controlled release step. Size the pool for the number of workers and feature runners. Queue claims rely on transactions; avoid transaction-pooling modes that break the operations used by your deployment.

Noir does not provision Postgres. Use Neon, Supabase, RDS, Railway, local Postgres, or the same database already used by the application.