A multi-tenant RAG document intelligence platform, with per-user data isolation.

Vector similarity search returns rows. Rows leak data. A single forgotten WHERE clause on a 10K-document index returns chunks from every customer at once — and the answer the LLM writes on top will be confidently grounded in someone else’s documents.

DocSense pushes isolation down to PostgreSQL. Every chunks row has a user_id foreign key to auth.users(id). Supabase row-level security policies enforce auth.uid() at query time. The match_chunks RPC takes p_user_id as a required filter parameter. The default state is safe: a backend developer (or an AI agent) cannot write a cross-tenant leak without first explicitly bypassing both the RLS policy and the RPC’s filter argument. The dangerous path requires intent.

The user accounts rollout was planned and executed in five phases — A (inventory), B (Supabase Auth + profiles), C (document and chunk ownership), D (usage tracking), E (API JWT middleware). Each phase had its own runbook, its own checklist, its own stable end state. The next phase didn’t start until the previous one was verified live.

Phase folders for billing, analytics, and auth were committed empty from day one — load-bearing signposts, not dead code. When the eventual code lands, the home is obvious and the import paths are stable. The same approach made the migration sequence work: 001 through 006 in strict order, with a dedicated repair migration (005) for any legacy database that had drifted off the spec.

File ingestion is where RAG systems accumulate technical debt fastest. Every new format becomes a special case, every chunking strategy a fork in the codebase, every change a regression risk.

DocSense uses abstract base classes for parsers (PDF, DOCX, TXT, OCR for images) and for chunking strategies. Adding a new format is a new subclass, not a touched switch statement. Repository-pattern data access keeps every query mockable. The ingestion pipeline reads as one straight line — parse, chunk, embed, store — and stays that way no matter how many formats land.

Per-user billing requires reliable usage events. The easy mistake is to record them asynchronously — a separate queue, a separate worker, a separate source of truth — and then spend forever reconciling the drift.

DocSense records every billable API call through a single record_usage Postgres RPC: one usage_events row written, one usage_monthly row upserted, inside the same transaction as the request that consumed the tokens. No second system, no batch reconciler, no async drift. Daily caps live in the same table — a single COUNT query returns a 429 when the user is over their limit. Billing becomes a SQL question, not a distributed systems problem.

Most RAG systems assume English. DocSense was built to handle non-Latin scripts — Gujarati in particular — without falling back to English-only embeddings. Migration 004 added a documents.language column with values gujarati, mixed, and other, surfaced in the UI as a small badge and used as retrieval metadata.

Embedding model selection is environment-configurable: text-embedding-3-small by default; switch to text-embedding-3-large with the dimensions parameter pinned at 1536, which keeps existing pgvector columns valid and avoids a database migration. Language metadata flows into retrieval, not just display — so a Gujarati query retrieves Gujarati chunks first, with mixed-script and English-fallback chunks behind them.