DuckTales: Fast Hardware Analytics with DuckDB
How Violet combines ontologies, agentic tools and DuckDB so hardware teams can easily generate insights across systems (without a line of SQL).
"How is procurement tracking against this assembly?"
If you're a hardware engineer, you know the pain of questions like this.
Part, purchase order, item receipt and schedule data live across multiple systems, in multiple formats, and with varied meanings.
We’re excited to share Violet's latest project that empowers users to solve this with agents - but lightning fast, and provably accurate.
Introducing project DuckTales: Violet's agent-first analytics stack, powered by the open source analytical system DuckDB.
Violet's agent-first analytics stack
How DuckTales works:
- Violet’s Ontology defines entity and relationship meaning across systems;
- Analytics Recipes give agents the tools to generate insights about your data in their native language; and
- DuckDB and DuckLake handle the analytical storage and query execution at breakneck speed.
Hardware questions are graph questions
Hardware engineering is known to be complex, and for a multitude of reasons.
Chief among them: hardware products, and the product development lifecycle itself, are highly coupled systems. The underlying data (bills of materials or BOMs, revisions, test results, suppliers, purchase orders, requirements, changes) is interconnected in complex and important ways.
This makes hardware programs graphs, and the questions teams need to answer graph questions.
For example:
- What's the part drawing release velocity on program X?
- Which parts are driving the overall cost in BOM Y?
- Which purchase orders for parts on BOM Z have been approved?
Typically, these types of questions are solved with SQL on top of manually aggregated data. This is slow, brittle and, by definition, human-in-the-loop.
Instead, could an agent chat directly with your data? This is feasible until the agent is faced with real hardware data. An LLM can write SQL - but it won’t reliably know that a part revision in Windchill is the same thing as a row in NetSuite, or that a release date in one system should be mapped to a certain procurement field in another.
Violet’s ontology is the shared semantic layer that solves this: it is a manufacturing-native vocabulary for entities, attributes, and relationships across your stack.
Recipes: Agentic analytical tools
Next, we surface tools that agents can use to query on this data. Our analytics Recipes are named, validated, reusable query specs with plain-English descriptions that agents can find and run.
These enable agents to respond to prompts with known steps, like:
- Look at this BOM
- Focus on Parts
- Track drawing release status over time
- Show cumulative progress
Under the hood, every recipe compiles through an internal step pipeline (scope, filter, aggregate, output) before SQL gets generated. A bounded vocabulary and validated parameters ensure predictable results.
Today, we use these in two ways:
Templates populate a catalog of pre-built recipes for things like cost rollups by schema, release velocity charts, BOM-scoped procurement matching. Agents start here to discover what’s available, pick a suitable template, fill in params, and run.
Composite recipes are for when nothing off the shelf fits. A custom release velocity chart can be generated for a specific environment, on a specific assembly, with team-specific property filters, all while still inside the same structured guardrails.
Violet’s agentic tools are all exposed through MCP, or Model Context Protocol - an open source standard for connecting tools to AI. Agents achieve each step in the typical flow with a tool: to discover what recipes exist, pick a template (or compose within the allowed shape), fill in parameters like BOM and filters, optionally validate with a dry run, then execute.
Duck-driven performance
Insights generated in Violet are analytical (roll up cost across a BOM, plot release velocity over time) and generally data-intensive (aggregate property coverage across thousands of entities).
To achieve this in a performant way, we’re incorporating DuckDB as a complement to our Postgres database.
DuckDB speeds up analytics because it processes data in a columnar, vectorized way rather than row by row. DuckLake is what provides lakehouse-style, tenant-isolated catalogs on object storage, so read-heavy analytics run off synced Violet data while Postgres stays the system of record.
This enables fast columnar queries over large datasets without standing up a warehouse for every deployment. Translation: lightning fast, real-time queries on massive datasets like assemblies or part inventories.
Where we’re headed
Hardware teams can’t rely on a chatbot that writes SQL. Their workflows require tools that understand the domain, expose trusted analytics as reusable objects, and have guardrails that empower agents to reliably work for them.
If you’re an engineer, program manager, or engineering leader dealing with cross-system BOM, procurement, or requirements questions, we'd love to hear how you’re thinking about it.
Reach out or book a demo here.
Abolish silos.
