Skip to main content
Retrieval Augmented Generation (RAG) grounds LLM responses in documents you control, rather than relying only on what the model learned during training. This example ships as RagExampleWorkflow in app/launchpad/workflows/examples/pgvector_rag/.
Instead of a dedicated vector database, you reuse the PostgreSQL instance the Launchpad already runs with the pgvector extension enabled.

Why pgvector?

  • Simple setup — no additional vector database; the default PostgreSQL service already has pgvector available.
  • Single source of truth — vectors live next to your relational data, so retrieval queries can join against business tables.
  • Cost effective — no separate vector database to operate or pay for.

Components

The workflow is a two-node pipeline: RetrievalNodeGenerationNode.

Retrieval

Generation

Running the example

1

Start the stack

From docker/, run ./start.sh to bring up the API, Celery worker, Redis, and PostgreSQL with pgvector. Supabase services and Caddy stay disabled unless you uncomment them in docker-compose.yml.
2

Apply migrations

From app/launchpad/, run ./migrate.sh so the pgvector extension and tables exist.
3

Insert embeddings

Use PgvectorRAGService directly to seed your collection:
4

Run the workflow

Use the dedicated playground script to exercise the whole pipeline against a sample query:
The script loads app/launchpad/workflows/examples/pgvector_rag/request_examples/query.json, instantiates RagExampleWorkflow, and prints the generated answer with sources and confidence.

Customization

  • Swap embedding model — pass a different embedding_model to PgvectorRAGService (default text-embedding-3-small, 1536 dims).
  • Change retrieval — adjust limit, measure, or metadata filters on collection.query(...) in RetrievalNode.
  • Change generation model — update model_provider / model_name in GenerationNode.get_agent_config.