AVAEngine selection
Set the engine in the AVA constructor. In the JavaScript API, omitting it always selects DuckDB; source type does not change this selection automatically.
| Engine | Sources | Runtime |
|---|---|---|
| DuckDB | Inline data, files, MySQL, PostgreSQL, SQLite, MongoDB | Node.js |
| JavaScript | Inline CSV, JSON, text | Node.js and browser |
| Python | Inline CSV / JSON; CSV / JSON / Parquet / Excel files | Node.js + Python executor |
| Supabase | Supabase project | Node.js; remote PostgreSQL |
| ClickHouse | ClickHouse database | Node.js; remote ClickHouse |
Engine configuration
| Field | Type | Required | Default / behavior |
|---|---|---|---|
engine.type | 'duckdb' / 'javascript' / 'python' / 'supabase' / 'clickhouse' / a registered name | When engine is provided | Omitting engine selects DuckDB. |
Additional fields depend on type: DuckDB options and Python options. JavaScript, Supabase, and ClickHouse accept no additional constructor engine fields. Database credentials belong to source parameters.
To run Python in your own service, see Supply a Python executor. To supply an engine from your application, see Custom engines.
Shared contract
Engines load data, discover schema, compute profiles, generate queries from supplied context, execute them, and release resources. AVA owns schema/profile caching and decides when discovery or computation is needed.
Applications normally use the AVA API. Implementers should follow the engine contract, including separate load() and schema() methods.
Registration
The Node.js entry point registers all five engines; the browser entry point registers JavaScript only. The registry keeps the core AVA class independent of platform-specific imports.
For SDK extensions, call registerEngine('sales', SalesEngine), then select engine: { type: 'sales' }. See Custom engines for the contract and a complete example. The CLI accepts only built-in engine names.