At most one database driver in active use
Why it matters
Two actively-used primary database drivers almost always means two separate databases, and every query that spans them is an application-side join with no transaction guarantee. A user update that writes to Postgres and then fails before writing to MongoDB leaves your data permanently inconsistent — there is no rollback across drivers. ISO 25010 functional-suitability degrades when the same logical entity is split across databases: foreign key relationships disappear, referential integrity becomes manual, and migrations must coordinate across two systems. AI-generated code is especially prone to this because each new session starts from scratch and reaches for whatever driver was convenient.
Severity rationale
Critical because cross-driver data splits eliminate transactional consistency, making partial writes and permanently inconsistent records routine rather than exceptional.
Remediation
Identify which driver owns fewer files and migrate its data to the primary database. Document the boundary explicitly if both databases are genuinely necessary.
# Find all files importing each driver
grep -rl "from 'pg'" src/
grep -rl "from 'mongodb'" src/
# After migrating the smaller side:
npm uninstall mongodb
rm src/db/mongo-client.ts
If both databases serve distinct purposes (e.g., Postgres for relational data, Redis for caching), document the boundary in src/db/README.md so the next AI session doesn't treat them as equivalent and start mixing queries.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Multi-Session Drift Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · functional-suitability — Functional correctness — split data sources risk inconsistency
Taxons
History
- 2026-04-18·v1.0.0·Initial import from ai-slop-code-drift·automated