docs: sync from backend c5db471 — request templates

02 - Data Models/MongoDB to PostgreSQL Migration Guide.md

@@ -4,7 +4,7 @@ tags: [data-model, migration, mongodb, postgres, mongoose, helper]
 aliases: [Mongo to Postgres, DB Migration Guide, Postgres Migration]
 created: 2026-05-31
 source: backend/src (automated multi-agent scan)
-updated: 2026-06-01 for backend integrate-main-into-development@1543b53
+updated: 2026-06-01 for backend integrate-main-into-development@c5db471
 ---
 
 # MongoDB → PostgreSQL Migration Guide
@@ -17,7 +17,7 @@ updated: 2026-06-01 for backend integrate-main-into-development@1543b53
 > **Execution plan:** see the companion [[MongoDB to PostgreSQL Migration Plan (Drizzle)]] for the phased, Drizzle-concrete plan (repository seam, `id_map`, dual-write, per-phase cutover runbook).
 
 > [!warning] Current implementation delta
-> This guide started as a migration helper. Backend `integrate-main-into-development@1543b53` now contains the first Postgres implementation layer: Drizzle schemas/migrations through `0009`, `src/db/client.ts`, `id_map`, `pg_dualwrite_gaps`, repository implementations/factory, backfill/verify scripts, conditional `payment_quotes` persistence, and aligned purchase/template request budget validation. Backend `2.8.17` also hardens the PurchaseRequest/SellerOffer backfill runner for marketplace-core dry-runs and selected-offer remapping, and enforces unique active marketplace categories by normalized visible name in Postgres mode. The broad service layer is still Mongoose-first and is **not** fully wired through those repositories. Use [[Postgres Runtime Cutover Status]] as the authoritative current-state snapshot.
+> This guide started as a migration helper. Backend `integrate-main-into-development@c5db471` now contains the first Postgres implementation layer: Drizzle schemas/migrations through `0010`, `src/db/client.ts`, `id_map`, `pg_dualwrite_gaps`, repository implementations/factory, backfill/verify scripts, conditional `payment_quotes` persistence, and aligned purchase/template request budget validation. Backend `2.8.19` also hardens the marketplace-core backfill runner for RequestTemplate/PurchaseRequest/SellerOffer dry-runs and selected-offer remapping, and enforces unique active marketplace categories by normalized visible name in Postgres mode. The broad service layer is still Mongoose-first and is **not** fully wired through those repositories. Use [[Postgres Runtime Cutover Status]] as the authoritative current-state snapshot.
 
 > [!info] Scan coverage (2026-05-31)
 > - **23** Mongoose models (collections)
@@ -2123,6 +2123,9 @@ CREATE TABLE purchase_request_service_info (
 
 Template marketplace objects that sellers create to define reusable service request specifications. Each template includes product/service details, budget expectations, delivery requirements, and optional default proposals used in marketplace discovery.
 
+> [!note] Implementation status
+> Backend `2.8.19` added `src/db/schema/requestTemplate.ts`, migration `0010_request_templates.sql`, and `src/db/backfill/backfill-requestTemplates.ts`. Runtime `RequestTemplateService` still uses Mongoose directly; this is a backfill/schema slice, not a read/write cutover.
+
 #### Fields
 
 | Path | Mongo Type | PG Type | Required | Notes |
@@ -2181,7 +2184,7 @@ Template marketplace objects that sellers create to define reusable service requ
 
 #### Gotchas & Migration Challenges
 
-1. **Embedded Subdocuments**: budget, deliveryInfo, serviceInfo, proposal, and metadata are nested objects. Choose JSONB columns for simplicity or denormalize to separate tables for relational queries (not needed initially).
+1. **Embedded Subdocuments**: budget, deliveryInfo, serviceInfo, proposal, and metadata are nested objects. Backend `2.8.19` denormalizes budget, delivery, service, proposal, metadata, and payment rails into scalar/array columns, while keeping `specifications` as JSONB.
 
 2. **String Arrays**: tags, attachments, images, specifications, and serviceInfo.requirements can use native PostgreSQL ARRAY type (faster queries) or JSONB (more flexible).
 
@@ -4747,7 +4750,8 @@ Each phase has explicit entry/exit criteria. The unit of migration is a bounded
 - **Entry:** Phase 4 exit. **Exit:** dispute lifecycle on PG; release-hold sync transactional.
 
 #### Phase 6 (optional / deferred) — RequestTemplate, BlogPost
-- Move behind a search abstraction; replace `$regex` with PG trigram/FTS only if you choose to migrate. Otherwise leave on Mongo.
+- RequestTemplate now has a PG table/backfill in backend `2.8.19` because template checkout creates marketplace-core rows; runtime service wiring is still Mongo-first.
+- BlogPost remains optional/deferred. Move it behind a search abstraction; replace `$regex` with PG trigram/FTS only if you choose to migrate. Otherwise leave on Mongo.
 
 #### Permanent on Mongo (no phase): Chat, Notification, TelegramSession, TempVerification, TelegramLink (link state)
 - Document-shaped + TTL-driven. Revisit only if operational cost of dual-stack outweighs migration cost.
@@ -4827,7 +4831,7 @@ Engineer-weeks (one mid/senior backend engineer-week). Ranges reflect genuine un
 | Aggregation pipeline rewrites (18, incl. $lookup/$facet) | 2 | 4 | Golden-output testing. |
 | Verification, load-testing, cutover ops per context | 2 | 4 | Shadow-read tooling, soak monitoring. |
 | **Partial migration — money/relational core only** (Phases 0–5 + cross-cutting) | **~16** | **~28** | This delivers the stated goal: ACID for money + relational integrity. |
-| Phase 6 RequestTemplate + BlogPost (search/aggregation, $regex→FTS) | 2 | 4 | Optional. |
+| Phase 6 BlogPost (search/aggregation, $regex→FTS) | 1 | 2 | Optional. RequestTemplate schema/backfill moved into the marketplace-core phase; runtime wiring remains. |
 | Chat + Notification + sessions full migration (embedded arrays, 3 TTL→pg_cron) | 5 | 9 | Only if going full-PG; this is the expensive long tail. |
 | **Full migration (all 23 collections)** | **~23** | **~40** | Plus integration/hardening contingency. |