You do not need a separate vector product on day one. You do need strict tenant filters, stable chunk IDs, and a way to re-embed when the model changes.

How should you design the schema?

Store documents and chunks as separate tables. Documents are the source of truth. Chunks are what you embed and retrieve.

-- Enable once per project
create extension if not exists vector;

create table knowledge_documents (
  id uuid primary key default gen_random_uuid(),
  workspace_id uuid not null references workspaces(id),
  title text not null,
  source_url text,
  status text not null default 'ready',
  created_at timestamptz not null default now()
);

create table knowledge_chunks (
  id uuid primary key default gen_random_uuid(),
  document_id uuid not null references knowledge_documents(id) on delete cascade,
  workspace_id uuid not null,
  chunk_index int not null,
  content text not null,
  token_count int,
  embedding vector(1536), -- match your embedding dimensions
  embedding_model text not null,
  metadata jsonb not null default '{}'::jsonb,
  created_at timestamptz not null default now()
);

create index on knowledge_chunks using ivfflat (embedding vector_cosine_ops)
  with (lists = 100);

alter table knowledge_documents enable row level security;
alter table knowledge_chunks enable row level security;

RLS policies must include workspace_id on every select. Never query embeddings with only a document id and hope the join is safe.

How do you chunk and embed without creating junk?

1. Normalize text (strip boilerplate, keep headings).
2. Split on structure first (headings, sections), then on size (roughly 300 to 800 tokens).
3. Overlap slightly so sentences at boundaries are not lost.
4. Keep chunk_index, document_id, title, and source URL on every row.
5. Embed with one model; write embedding_model on every chunk.
6. Re-embed the whole corpus when you change models. Do not mix dimensions or model families in one index.

Ingest from a Next.js route or a background job. Prefer a job queue for large uploads so the request path stays fast.

// Illustrative ingest step (server-only)
import { createClient } from "@supabase/supabase-js";
import { embedTexts } from "@/lib/embeddings";

export async function upsertChunks(params: {
  workspaceId: string;
  documentId: string;
  chunks: string[];
  model: string;
}) {
  const supabase = createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY! // server only
  );

  const vectors = await embedTexts(params.chunks, params.model);

  const rows = params.chunks.map((content, chunk_index) => ({
    document_id: params.documentId,
    workspace_id: params.workspaceId,
    chunk_index,
    content,
    embedding: vectors[chunk_index],
    embedding_model: params.model,
    metadata: { version: 1 },
  }));

  const { error } = await supabase.from("knowledge_chunks").upsert(rows);
  if (error) throw error;
}

Use the service role only on the server. Browser clients must go through RLS-scoped APIs.

How should retrieval work in the API route?

Retrieve first, then generate. Cap top-k, require a minimum similarity, and always filter by workspace_id.

A typical pattern is an RPC like match_knowledge_chunks(query_embedding, workspace_id, match_count) that applies the filter inside Postgres, then a Next.js route that builds the prompt and calls the LLM.

What belongs on the pre-launch checklist?

Use this as a go / no-go list before you open the feature to customers.

• One embedding model pinned; dimensions match the column
• Chunks have stable ids, source metadata, and overlap
• RLS (or equivalent) filters every retrieval by tenant
• Service role keys never ship to the browser
• Re-ingest path exists for doc updates and model changes
• Top-k and score threshold are configurable without a redeploy
• Empty or low-confidence retrieval returns a clear refusal
• Prompt instructs the model to use only provided context
• Small eval set (10 to 30 questions) runs in CI or a script
• Cost and latency logged per request
• Delete path removes chunks when a document is deleted
• Rate limits on ingest and chat endpoints

How do you add lightweight evals before launch?

You do not need a research lab. You need a spreadsheet of real questions, expected doc ids or must-include phrases, and a script that fails the build when retrieval or answers regress.

1. Collect 10 to 30 questions from support tickets or founder FAQs.
2. Label the document (or chunk) that should be retrieved.
3. Run retrieval-only checks on every ingest change.
4. Run answer checks on a fixed prompt and model version.
5. Track hit rate, refusal rate, and median latency.

If retrieval is wrong, fix chunking and filters before you tweak prompts.

What usually breaks in production?

How Luminix Studio ships RAG for startups

Luminix Studio builds web and mobile apps and the AI automations around them for startups worldwide. For RAG features we usually start on Next.js and Supabase pgvector, prove retrieval quality with a small eval set, then layer chat UI and agent tools once the checklist above is green. If you want help scoping or shipping that path, see luminixstudio.com.