Spent the last 8 months shipping MarsRAG into compliance-heavy orgs (finance, healthcare-adjacent), and the pattern is always the same: teams build a great retrieval pipeline, then get blindsided in the audit because nobody designed for provable erasure.

Here's the thing most RAG tutorials skip — GDPR Article 17 doesn't care that you "deleted the user row." Auditors want to see that the embeddings derived from that user's documents are gone too, with no orphaned vector fragments floating in your index. If your vector store is a separate service from your relational DB (Pinecone + Postgres, Weaviate + Mongo, whatever), you now have two deletion paths to keep in sync, and one of them is a black box you don't control.

The fix that worked for us: collapse vector storage, relational data, and auth into one engine. We run everything on Supabase Vector (pgvector on Postgres) — which means deletion is a single transactional DELETE with foreign-key cascades across text, metadata, and embeddings. No sync jobs, no "trust me it's deleted" API calls to a third-party vector host.

Two other things that mattered more than expected:

• Row-Level Security at the DB layer, not app layer. Tenant isolation enforced by Postgres RLS tied to auth tokens means a bug in your application code literally cannot leak another tenant's data — the database won't return rows it doesn't have to.

• Fewer sub-processors = faster vendor security reviews. Every SaaS vector DB and auth provider you add is another DPA a security team has to review. Cutting from 5 sub-processors to 1 shaved about 4 weeks off a recent SOC 2 vendor review.

If you're building RAG for anything touching regulated data, design your deletion story before you design your retrieval story. It's much harder to retrofit.

Happy to go deeper on the architecture if useful.