DuckDB can now run language-model calls and retrieval-augmented generation inside SQL, but not because DuckDB shipped the feature. A research extension called FlockMTL, described in a short PVLDB 2025 paper by its authors, “Beyond Quacking: Deep Integration of Language Models and RAG into DuckDB” (PVLDB 18(12), 2025; arXiv 2504.01157), promotes PROMPT and MODEL to first-class schema objects next to TABLE and applies cost-based batching and caching to LLM execution. Every performance and design claim is author-reported, with no independent replication as of 2026-09-15. The practical consequence: if your corpus already sits in Parquet, Iceberg, or Delta, semantic analytics may no longer need a separate vector store, and the new bottleneck moves into SQL governance.
What FlockMTL actually changes in DuckDB SQL
The paper’s core move is to treat prompts and models as database objects rather than application-layer configuration. Per the authors’ abstract, FlockMTL “incorporates: (i) cost-based optimizations, which seamlessly apply techniques such as batching and caching; and (ii) resource independence, enabled through novel SQL DDL abstractions: PROMPT and MODEL, introduced as first-class schema objects alongside TABLE.”
Two mechanisms matter here. First, resource independence: a query can reference a named MODEL or PROMPT object without the query author managing endpoints, keys, or template strings inline. The schema owns the binding, the way a TABLE owns its columns. Second, cost-based optimization: the engine, not an orchestration layer, decides when to batch LLM calls and when to serve from cache. In a conventional RAG stack, batching and caching live in application code or a proxy like a gateway service; FlockMTL’s design intent is to push those decisions down to the query planner, which already knows the cardinality of the rows being processed.
That is a real architectural claim, and it should be read as design intent. No public third-party evaluation exists as of 2026-09-15: no measured latency figures, no cost numbers, and no independent test of whether the planner’s batching decisions beat a hand-tuned orchestration layer in practice. Treat the cost-based optimization framing as a hypothesis about favorable conditions, not an observed result.
Where the data already lives
The reason in-database retrieval is plausible at all is DuckDB’s existing footprint. DuckDB is an in-process SQL OLAP database that runs embedded in the application using it, with clients for Python, R, Java, and Wasm per the project repository. It reads CSV, JSON, Parquet, Iceberg, and Delta Lake from local filesystems, HTTP endpoints, and cloud blob stores including S3, R2, Azure Blob Storage, and Google Cloud Storage, according to MotherDuck’s tutorial. Wikipedia describes it as a column-oriented engine built for complex queries against tables with hundreds of columns and billions of rows.
In other words, the typical DuckDB user is already pointing SQL at the same analytical file formats where document corpora, logs, and knowledge bases tend to accumulate. Groundy has previously shown how far this pattern goes: DuckDB can even query remote Parquet over HTTP without downloading full files. The conventional RAG architecture asks that user to export the corpus, embed it, load it into a vector store, and operate a second system with its own scaling and access-control story. FlockMTL’s pitch is to delete that export step and run semantic queries where the data already lives.
The delivery mechanism is worth pausing on. This is not a core DuckDB feature. DuckDB supports dynamically loaded extensions, and Wikipedia counts over 30 community extensions covering graph queries, Kafka integration, and ML inference. FlockMTL arrives through that channel as a research extension attached to an academic paper. Nothing in the public record shows it on a DuckDB roadmap or shipping in a release.
Stewardship context adds timing pressure to the question. In August 2026, Amazon acquired DuckLabs (formerly DuckDB Labs), with employees joining the AWS subsidiary, according to Wikipedia accessed 2026-09-15, and the project announced the acquisition on its own site, so the event is not solely Wikipedia-sourced. The same Wikipedia page puts the project at over 6 million downloads per month, an undated figure. The DuckDB Foundation, an independent non-profit, still safeguards long-term maintenance, but an acquisition of the primary commercial steward makes the extension ecosystem’s direction a legitimate question for teams planning multi-year architecture on it.
In-database RAG vs the vector-store stack
The decision is not “RAG or no RAG.” It is where retrieval execution and its governance live:
| Decision axis | In-database RAG (FlockMTL design) | External vector-store stack |
|---|---|---|
| Workload fit | Analytical scans over large tables; DuckDB is specialized for OLAP | Interactive serving; vector stores are built for low-latency point lookups |
| Cost mechanics | Engine-managed batching and caching (author-reported intent, unmeasured) | Per-call spend managed in orchestration code or gateways, visible to application teams |
| Governance surface | PROMPT/MODEL as SQL DDL objects, auditable through schema and permissions | Prompt stores, orchestration configs, and vector-store ACLs spread across systems |
| Data locality | Query Parquet/Iceberg/Delta in place, no export | Export, embed, and load pipeline between systems |
| Deployment | In-process, embedded with the application | Client-server infrastructure to provision and operate |
| Maturity | A short author-reported PVLDB 2025 paper, peer-reviewed but not replicated | Established ecosystem with known operational failure modes |
Read the maturity row carefully, because it cuts against the tidy story in the other five. The vector-store stack’s advantage is not elegance; it is that its failure modes are documented and staffed. “Established” does not mean “solved.” It means the problems are known. FlockMTL’s problems are not yet known.
The new bottleneck moves into DDL
The angle that matters most for practitioners is not the retrieval mechanics. It is what the abstraction does to accountability.
When PROMPT and MODEL are schema objects, prompt versioning becomes schema migration. Changing a template is a DDL change, subject to whatever change-control, review, and rollback practices a team applies to table definitions. Model cost accounting becomes a database resource question: which role ran which MODEL object how many times, against how many rows. Access control for semantic queries becomes an extension of SQL grants, where the person who can read a table may implicitly gain the ability to run an LLM over its contents.
Each of those is a genuine improvement in principle, because SQL databases have mature permission and audit machinery that prompt stores and orchestration layers typically lack. It is also a staffing problem in practice. Most analytics teams do not audit DDL changes for semantic meaning. A CREATE OR REPLACE PROMPT statement that subtly alters instructions to a model looks identical in a migration log to a cosmetic rename unless someone builds review practice around it. Cost accounting faces the same gap: a query planner that batches LLM calls is making spending decisions, and the DBA tooling most teams run has no concept of token budgets.
This is the quiet tradeoff the paper’s framing does not emphasize. The paper itself treats in-database RAG as an optimization and integration story. It does not frame it as an audit-surface migration, which is where the actual adoption cost will land.
What the evidence does not show
The honest inventory of gaps:
- No independent replication. Every design and performance claim traces to the authors’ own PVLDB 2025 paper, a short peer-reviewed entry. Peer review is not replication: no public third-party benchmark, production deployment, or measured latency or cost figure exists as of 2026-09-15.
- No comparison to the incumbent approach. There is no pgvector head-to-head, no latency envelope for in-engine retrieval versus a dedicated vector store, and no cost-per-query accounting. Any such numbers would need new sourcing; none are public as of 2026-09-15.
- OLTP limits on serving. DuckDB explicitly does not target transactional applications. A user-facing retrieval path with per-request latency budgets and concurrent sessions is exactly the workload DuckDB opts out of. In-database RAG via FlockMTL inherits that constraint: it is a design for analytical scans, not for serving retrieval behind a product.
- Maturity unknowns. The public record shows a research paper, not a maintained community extension with a release cadence. Nothing public puts FlockMTL on a DuckDB roadmap or in a release as of 2026-09-15, so check its shipping status directly before relying on it.
Who should adopt now, and who should wait
For teams whose corpora already sit in Parquet, Iceberg, or Delta reachable from DuckDB, FlockMTL is worth a sandboxed evaluation today. The combination of PROMPT and MODEL schema objects with engine-managed batching and caching makes in-SQL semantic analytics a credible default for offline workloads: document classification over large tables, corpus exploration, embedding-driven joins where the alternative is an export pipeline. The extension model means the experiment costs a weekend, not a platform commitment.
Keep latency-sensitive serving paths on OLTP-capable stores. DuckDB’s own positioning excludes that workload, and nothing in the paper changes the engine’s fundamental architecture.
Before anything ships to production, stand up the governance the abstraction demands: DDL-level review for PROMPT and MODEL changes, a cost-accounting practice that attributes LLM spend to schema objects and roles, and explicit thinking about what a SQL read grant means when reading includes model inference. These are solvable problems, but they are new problems for the teams most likely to adopt this first.
The strongest limitation on all of the above is the evidence base itself: a single short paper by the authors, peer-reviewed but not independently replicated. The claim that in-database RAG moves the bottleneck into SQL governance and cost accounting is an inference from the design, not an observed outcome. That inference is well-supported by how SQL permission and audit machinery works, but the FlockMTL half of the story remains a hypothesis until someone outside the author group runs it and publishes the numbers.
Frequently Asked Questions
Is FlockMTL a core DuckDB feature or a separate extension?
This is not a core DuckDB feature. DuckDB supports dynamically loaded extensions, and Wikipedia counts over 30 community extensions covering graph queries, Kafka integration, and ML inference. FlockMTL arrives through that channel as a research extension attached to an academic paper. Nothing in the public record shows it on a DuckDB roadmap or shipping in a release.
What data formats can DuckDB read for in-database RAG?
It reads CSV, JSON, Parquet, Iceberg, and Delta Lake from local filesystems, HTTP endpoints, and cloud blob stores including S3, R2, Azure Blob Storage, and Google Cloud Storage, according to MotherDuck’s tutorial.
Does DuckDB support transactional applications for serving retrieval?
DuckDB explicitly does not target transactional applications. A user-facing retrieval path with per-request latency budgets and concurrent sessions is exactly the workload DuckDB opts out of. In-database RAG via FlockMTL inherits that constraint: it is a design for analytical scans, not for serving retrieval behind a product.
