Incoming queries
A continuous stream of queries hits the system. Dashboards, reports, pipelines, ad-hoc questions: at this point they all look the same. Just SQL, arriving nonstop.
The router decides
Ahead of time, SynnoDB studies your workload and synthesizes code for the queries it can accelerate. Every query then enters through the SynnoDB-WL-Router, which detects, per query, whether SynnoDB has a synthesized fast path for it. A uniform gray stream goes in. Two colored streams come out.
Synthesized queries
Queries SynnoDB has synthesized turn toward the Bespoke Engine: storage layout and execution code generated for exactly those queries, held entirely in memory. On the queries it covers, expect order-of-magnitude speedups.
Everything else
Every other query - shapes SynnoDB has not synthesized, rare or ad-hoc questions - is routed to your existing general-purpose analytical engine. It answers correctly, backed by persistent storage on disk. No query is left behind.
One source of truth
The two engines are not two databases. At startup, the Bespoke Engine loads its data from the general-purpose engine into memory. Disk remains the single source of truth; the synthesized fast path is an accelerator in front of it.
The whole system
SynnoDB analyzes your workload, synthesizes a bespoke engine for the queries it can accelerate, and routes each one to the right place - falling back to your existing engine for the rest. Same SQL, same results, a fraction of the time. This walkthrough uses DuckDB as the example, but the same architecture sits in front of any general-purpose analytical engine - Snowflake, Redshift, Big Query, ... - and works exactly the same way.