TendSocial Prisma Postgres DB Spike

Purpose

This package breaks the Prisma Postgres evaluation and DB optimization work into implementation-ready phases for TendSocial.

TendSocial is already Prisma-based, media is stored in Cloudflare R2, and the relational database primarily stores text and product state: users, workspaces, campaigns, content drafts, blog posts, schedules, social account metadata, publishing state, and related operational records. That makes Prisma Postgres a strong candidate, but only if TendSocial controls Prisma operation count.

Prisma's current pricing is operation-based: Free includes 100k operations and 500 MB; Starter is $10/month with 1M operations and 10 GB; Pro is $49/month with 10M operations and 50 GB; Business is $129/month with 50M operations and 100 GB. Prisma defines an operation as each Prisma ORM interaction with the database, not every SQL statement generated behind it. Source: Prisma pricing.

Files

File	Phase
01-prisma-postgres-setup.md	Create Prisma Postgres DBs, split pooled/direct connection settings, run initial schema creation and seeding.
02-operation-test-suites.md	Build three operation-measurement test suites: backend API, standard Playwright flows, and exhaustive Playwright action crawl.
03-db-tuning-n-plus-one-query-shape.md	Remove N+1 patterns, over-fetching, repeated context loads, unbounded pagination, and inefficient write patterns.
04-indexing-plan.md	Add measured, workload-driven indexes around TendSocial's actual tenant-scoped access patterns.
05-caching-plan.md	Reduce database operations through Prisma Accelerate/query caching, short-lived server caches, and safe HTTP caching.
06-analytics-event-log-offload.md	Identify current analytics/event/log writes in Prisma and move high-volume streams to better destinations.
07-decision-gate-and-rollout.md	Define go/no-go criteria, rollout approach, and rollback expectations before making Prisma Postgres primary.

High-level implementation sequence

1. Stand up Prisma Postgres environments.
2. Add split database connection handling.
3. Build repeatable seed data.
4. Add request/action-level DB operation measurement.
5. Run API and Playwright operation tests.
6. Fix the most expensive query paths.
7. Add measured indexes.
8. Add caching for repeated safe reads.
9. Move analytics/event/log streams out of Prisma.
10. Re-run benchmarks.
11. Decide whether to cut over.

Target decision

The expected target outcome is:

Primary DB direction: Prisma Postgres
Supabase role: auth only
Cloudflare R2 role: media and raw archive storage
Neon role: temporary fallback during evaluation only

Success criteria

Gate	Target
Prisma Postgres setup works from a clean repo	Yes
Runtime uses pooled Prisma Postgres URL	Yes
Migrations/admin use direct Prisma Postgres URL	Yes
Seed data represents realistic TendSocial usage	Yes
Backend API operation report generated	Yes
Standard Playwright operation report generated	Yes
Exhaustive Playwright action report generated	Yes
Top DB hot spots identified	Top 20 minimum
Top hot spots fixed or ticketed	100%
High-volume analytics/event/log writes removed from Prisma	Yes
50-user estimate fits Prisma Pro or lower	Preferred
500-user estimate fits Prisma Business or lower	Preferred
Rollback path documented	Yes

Key source references

• Prisma pricing
• Prisma Postgres connection pooling
• Prisma Client logging
• Prisma query optimization
• Prisma indexes
• Playwright authentication
• Playwright network monitoring
• PostHog pricing
• Cloudflare R2 pricing
• Axiom pricing
• Tinybird pricing
• Google Cloud Free Tier
• Langfuse pricing