Two databases on purpose: Postgres and MongoDB, each where it fits

"Why are you using two databases?" is a fair interview question, and the wrong answer is "because I could." The right answer names a workload that each store is genuinely better at.

The split

PostgreSQL owns anything with transactional, relational integrity requirements:

• users, with a unique email
• refresh_tokens, with family + rotation tracking and reuse detection
• subscribers and audit_logs

Foreign keys, uniqueness, and ACID are the point. Refresh-token rotation in particular needs strong invariants — a replayed token should kill the whole session family in one transaction.

MongoDB owns append-heavy, schema-flexible, and vector workloads:

• analytics_events (with a TTL index to respect free-tier storage)
• contact_messages
• reserved: chat transcripts and embeddings for a later semantic-search phase

The rule that keeps it honest

One writer per concern. No entity is dual-written to both stores.

The moment the same record lives authoritatively in two places, you've signed up for a distributed-consistency problem you didn't need. Cross-store access is read-only read models, nothing more.

Free-tier discipline

Both stores are on free tiers (Neon and Atlas M0), so the design has to respect their limits: pooled Postgres connections (no client-per-request), lean Mongo documents, TTL cleanup on the event stream, and indexes on the hot paths.

Polyglot persistence isn't about collecting databases. It's about refusing to force one model onto a workload it doesn't fit.