Registration

The plugin is registered on tauri::Builder like any Tauri v2 plugin. There are two entry styles: a one-liner init() with defaults, or a per-backend Builder that configures migrations, the security policy, connection hooks, and checkpoint strategies before building.

Simplest: `init()`

init() builds the plugin with a permissive policy, no migrations, and passive checkpointing.

backend-core
backend-diesel

fn main() {
    tauri::Builder::default()
        .plugin(better_duck_tauri::core::init())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

fn main() {
    tauri::Builder::default()
        .plugin(better_duck_tauri::diesel::init())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

core::init() is gated behind feature = "backend-core"; diesel::init() behind feature = "backend-diesel". This is exactly what the example app uses.

Configured: the per-backend `Builder`

For anything beyond defaults, use core::Builder / diesel::Builder. Every setter is chainable and #[must_use], and build() produces the TauriPlugin you pass to .plugin(…).

use better_duck_tauri::{core::Builder, Migration, MigrationKind};

tauri::Builder::default()
    .plugin(
        Builder::new()
            .add_migrations("duckdb:app.db", migrations)      // Vec<Migration> (core)
            .read_only(false)
            .allow_connection("duckdb:app.db")
            .allow_path("/data")
            .deny_risky_statements(true)
            .allow_network(false)
            .checkpoint_interval(std::time::Duration::from_secs(300))
            .checkpoint_on_exit(true)
            .on_connect(|c| {
                my_udf::register(c)
                    .map_err(|e| better_duck_tauri::Error::Backend(e.to_string()))
            })
            .build(),
    )
    .run(tauri::generate_context!())?;

Builder methods

Builder

Creates an empty builder (equivalent to Default).

Builder

Registers migrations to run on load for a connection string. The core builder takes a Vec<Migration> (repeatable — entries extend); the diesel builder takes an EmbeddedMigrations from embed_migrations! (one per connection string). See Migrations.

Builder

Opens databases READ_ONLY and rejects write operations (execute / import / append_rows / revert). See Scope & Policy.

Builder

Restricts load to this exact connection string. Repeatable — each call appends to the allow-list.

Builder

Restricts import/export to files resolving within this directory. Repeatable; paths are canonicalized and prefix-checked.

Builder

Rejects statements whose leading keyword is risky (ATTACH / DETACH / INSTALL / LOAD / PRAGMA / COPY / SET / CALL / EXPORT / IMPORT) in select / execute / export / explain.

Builder

Allows loading network-backed extensions (httpfs / aws / azure). Off by default — these enable SQL-driven network egress.

Builder

Registers a Fn(&mut Connection) -> Result<()> run on every opened connection — the place to register UDFs or LOAD extensions so each connection carries them. Repeatable.

Builder

Automatic strategy: sets DuckDB’s checkpoint_threshold (e.g. "64MB") at load.

Builder

AfterWrites strategy: checkpoint after every n-th write operation.

Builder

Interval strategy: a background thread checkpoints all loaded connections this often.

Builder

OnAppLifecycle strategy: checkpoint all connections on the Tauri Exit event.

Builder

Use FORCE CHECKPOINT (waits for the lock) for background / after-write sweeps.

Builder

Applies the per-platform default strategy set: mobile (Android/iOS) enables OnAppLifecycle + FORCE CHECKPOINT; desktop stays passive. Merges under anything you set explicitly.

TauriPlugin<R>

Assembles the engine and returns the plugin.

The checkpoint setters are detailed in Checkpointing; the policy setters in Scope & Policy.

The only difference between core::Builder and diesel::Builder is add_migrations: core takes Vec<Migration>, diesel takes EmbeddedMigrations. Every other method is identical, and the resulting webview command surface is the same.

Host-side re-exports

For writing hooks and host code, the crate re-exports:

use better_duck_tauri::{
    Connection,                 // core DuckDB connection, for on_connect hooks
    DuckBackend, Row, ExecuteResult, DataFormat,
    Migration, MigrationKind,   // core migration model
    Policy, CheckpointConfig, EngineConfig, ConnectHook,
    Error, Result,              // plugin error + result alias
    scope,                      // pub mod scope — the Entry schema type
};

Diesel builder shape

The configured diesel builder differs only in the migration type:

use better_duck_tauri::diesel::Builder;
use diesel_migrations::{embed_migrations, EmbeddedMigrations};

const MIGRATIONS: EmbeddedMigrations = embed_migrations!("migrations");

tauri::Builder::default()
    .plugin(
        Builder::new()
            .add_migrations("duckdb:app.db", MIGRATIONS)
            .checkpoint_platform_defaults()
            .build(),
    )
    .run(tauri::generate_context!())?;

Getting Started

Frontend API

Backends & Persistence

Security

Simplest: `init()`

Configured: the per-backend `Builder`

Builder methods

Host-side re-exports

Diesel builder shape

See also

​Simplest: init()

​Configured: the per-backend Builder

​Builder methods

​Host-side re-exports

​Diesel builder shape

​See also

Simplest: `init()`

Configured: the per-backend `Builder`

Builder methods

Host-side re-exports

Diesel builder shape

See also