Cross-primitive Recipes

These recipes span multiple K3 engines in a single workflow. They come in two groups: querying — using the engines directly over the wires you already know (SQL, Bolt, vector clients, GraphQL) — and ingest automation — pipelines that fan uploaded objects out into rows and embeddings for you.

For recipes scoped to a single primitive (Storage’s browser upload, Vector’s hybrid search, Tables’ time-travel, etc.) see the per-primitive recipe folders.

Query your data — the engines, converged

Every bucket’s tables are simultaneously a SQL surface, a vector-search target, and a graph node set — no copies, no sync. Start here:

Recipe	Engines involved	When you need it
Converging Engines	SQL · Vector · Graph · GraphQL	The flagship: pgvector KNN in SQL, `CREATE GRAPH` over the same rows, similar-then-walk-the-graph pipelines, and one GraphQL query that returns relational columns + `_score` + a nested edge traversal in a single response.

Supporting pages: Data Engines (the four-engine map), Connect & wire adapters (psql on pg.uk-lon-1.dodil.io:5432 with sslmode=require, neo4j drivers on bolt+s://bolt.uk-lon-1.dodil.io:7687, Qdrant/Pinecone SDKs, dodil data sql | pg | bolt | vsearch), and the per-engine docs — SQL, Vector, Graph.

Automate ingest — pipelines fan objects out

One upload becomes searchable embeddings and structured rows automatically:

Recipe	Primitives involved	When you need it
RAG Knowledge Base	Storage · Pipelines · Vector	Drop PDFs in a bucket → search them semantically. The canonical “Hello, K3” full-stack scenario.
Mixed-Media Library	Storage · Pipelines · Vector	Upload images / video / audio → search by visual similarity or by file. Showcases multimodal end-to-end.
Reviews Dashboard	Storage · Pipelines · Tables + Vector (parallel)	One upload kicks two pipelines: sentiment analysis to a warehouse table + semantic embeddings to a vector collection. Same bucket, both pillars indexed.
Document Intake	Storage · Pipelines · Tables + Vector (parallel)	Similar fan-out shape: `document_triage` → Tables for routing logic, `text_embedding_index` → Vector for semantic recall. Every uploaded document feeds both decision-making and retrieval.

Fast path: dodil data recipe install <id> -b <bucket> provisions a collection / table / pipeline / rule stack in one command (--dry-run prints the plan first) — see Pipelines → CLI → recipe. Eight recipes ship:

id	Group	What it provisions
`document-rag`	rag	Vector collection (`text_embedding_index`) + rule for pdf/docx/md/txt/html
`code-rag`	rag	Vector collection (`code_embedding_index`) + rule for source-code globs
`image-rag`	rag	Vector collection (`visual_embedding_index`) + rule for jpg/png/webp/heic
`invoice-intake`	intake	Table pipeline (`invoice_parsing`) + rule
`transcription`	intake	Table pipeline (`audio_transcription`) + vector collection (`text_embedding_index`) + one rule on the vector side
`summarize-to-markdown`	processing	Object pipeline (`summarization`) writing under `summaries/` + rule
`summarize-then-rag`	combo	The above, plus a vector collection over `summaries/**`
`generic`	generic	Vector collection + `classification` and `summarization` table pipelines

Only document-rag matches a recipe on this page one-for-one (the RAG Knowledge Base flow). There is no mixed-media-library, reviews-dashboard, document-intake or converging-engines recipe id — build those from the steps on their pages. Resources are named <prefix>_<suffix> where the prefix defaults to the recipe id with dashes turned into underscores; override it with --name-prefix.

The ingest fan-out pattern


   Storage bucket  ──upload──►  one or more ingest rules
                                          │
                                          ▼
                            ┌─────────────┴─────────────┐
                            │                           │
                            ▼                           ▼
                    Vector collection           Warehouse table
                  (semantic retrieval)          (structured rows, SQL)
                            │                           │
                            ▼                           ▼
                     search route              Execute / Query RPCs

The fan-out happens because a bucket can have multiple ingest rules, and each rule targets one pipeline which writes to one destination. Want a Tables-bound copy of every uploaded doc AND a Vector-bound copy? Wire two pipelines on the same source, each with its own auto-generated rule.

Conventions used in these recipes

Native client first. SQL examples use psql / psycopg, graph examples use a neo4j driver over bolt+s://, object examples use boto3 / aws-cli, GraphQL examples are graphql fences. curl appears where a route has no native client.
Two different planes. The control plane (https://api.data.dodil.io) owns buckets, sources, pipelines, ingest rules and POST /:bucket/search/vector. Table DATA, DDL, ad-hoc SQL, vector KNN and graph traversal belong to the tables-gateway — reached over the Postgres wire, Bolt, the Qdrant/Pinecone adapters, GraphQL, or POST /v1/databases/{db}/… on the tables HTTP door. The old /:bucket/tables/* data routes are gone.
Bucket placeholder is kb-platform; tables and vector capacity are implicit per bucket — there is no engine plane and nothing to enable.
A vector collection is a pipeline with a vector facet. Its identity is the pipeline id, which is what vector collection get|delete take.
Consistent example collections / tables across recipes:
- docs — vector, pipeline-mode, text_embedding_index
- assets — vector, pipeline-mode, visual_embedding_index
- reviews / reviews_vec — table + vector, review_analysis + text_embedding_index
- intake / intake_vec — table + vector, document_triage + text_embedding_index

Cross-primitive Recipes

Query your data — the engines, converged

Automate ingest — pipelines fan objects out

The ingest fan-out pattern

Conventions used in these recipes

See also