chore(db): tune document autovacuum for connector sync churn

[waleedlatif1]

Summary

• Sets per-table autovacuum scale factors on document so connector sync churn triggers cleanup well before the default 20% threshold would
• Table-local storage parameters only: no row rewrite, no schema change, and no effect on existing readers or writers

Why

Connector syncs update this table in bursts large enough to outrun autovacuum at the default scale factor. Once dead rows accumulate, index-only scans can no longer trust the visibility map, so the knowledge base listing's token aggregate degrades into per-row heap fetches and the request can exceed its statement timeout.

Comparing the same query and the same data before and after autovacuum had caught up — with no change to the query, its indexes, or the schema — showed an order-of-magnitude difference in execution time, driven entirely by how many heap fetches the aggregate had to perform. The bloated case did not complete within the statement timeout.

Why these values, and not 0357's

0357 set more aggressive factors on outbox_event, a small queue table. This is one of the largest tables here and shares a small autovacuum worker pool with many other large tables, so triggering too eagerly would risk holding a worker continuously and starving its peers. These factors still trigger several times earlier than the defaults without monopolising the pool.

Per-table storage parameters are the documented mechanism for this. Cost limit and cost delay are deliberately left unset: PostgreSQL excludes tables carrying either from cross-worker I/O balancing, which is not a trade worth making on a table this busy.

What this does not fix

Even fully vacuumed, the listing aggregate scans the table's index entries for the knowledge base on every request and remains slow. That baseline is architectural rather than a maintenance problem and needs its own change.

Type of Change

• Chore / maintenance

Testing

bun run check:migrations origin/staging passes (backward-compatible). Lint, check:audits (46 audits), docs-manifest:check, and type-check pass. Snapshot chain verified: 0362.prevId == 0361.id and the snapshot content is identical apart from the id pair, matching how 0357 recorded a settings-only migration.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Sep 18, 2026 5:55am UTC

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge with no actionable correctness, security, or migration-chain issues identified.

Summary

Adds a storage-only PostgreSQL migration that tunes autovacuum for connector-driven churn on the document table.

• Lowers the table-local vacuum scale factor to 0.05 and analyze scale factor to 0.02.
• Preserves existing table storage parameters and makes no schema or row-format change.
• Extends the Drizzle snapshot and journal chain without introducing schema drift.

_{Reviews (1) · Last reviewed commit: 9bffde0}