How Apache Superset with DuckDB and MotherDuck works
A team that wants dashboards over Parquet files, CSV exports or small analytical datasets often does not want to run a server warehouse just to get there. Superset can serve that need through DuckDB, an in-process analytical engine. Superset connects to DuckDB through the duckdb-engine driver, and the Superset database catalog lists the connection strings for three cases: a local database file such as duckdb:////path/to/duck.db, an in-memory database, and MotherDuck, the hosted service built on DuckDB. The catalog also describes DuckDB as able to read CSV, Parquet and JSON, which is what makes it useful for file-based analytics. This page covers how those pieces fit together, the decisions they force, and what to verify before a rollout. It does not cover the DuckDB or MotherDuck products themselves, their pricing or their feature roadmaps, which you should confirm with their documentation and vendor.
The first decision is where the data lives and who can reach it. A local file database is attached to a path on the Superset host or container, so the file must be present where the Superset workers and web nodes run, and every container that needs it must see the same path. An in-memory connection holds no data between sessions and is suited to querying files directly from a path or URL that the engine can read. MotherDuck moves the database to a hosted service and authenticates with a token passed in the motherduck_token parameter of the connection string. Each option changes who can write, how backups are taken and where credentials are stored, so confirm those answers before you choose a pattern. Because DuckDB runs inside the process that executes queries, a file-backed database also carries single-writer constraints that shape how many users can refresh or change data at once.
Keep the boundaries of this page in view. Superset still needs its own metadata database, and the Superset architecture documentation treats the SQLite default as unsuitable for production, so DuckDB never replaces that component. Query access, row-level restrictions and caching are governed by Superset roles and by the rights you grant on the DuckDB file or MotherDuck database, and those need separate design. Before going further, check the database catalog entry for your Superset version, confirm the duckdb-engine and duckdb package versions that your image will install, and test a representative Parquet or CSV query against the exact connection string you plan to use.
What you need before connecting DuckDB or MotherDuck to Superset
DuckDB and MotherDuck connect to Superset through a driver inside the Superset image, not through a separate service you add to the stack. Each card below is a prerequisite that has to be settled before the first connection test, because a missing package, a blocked outbound route or an unmanaged token will stop the connection in ways that look like a Superset fault.
A Superset image with duckdb-engine
Superset loads database drivers from its own Python environment, so the duckdb-engine package must be installed in the image that runs the web server and the workers. Confirm the package version against the Superset release you run, since supported driver versions change between releases. Check that the image you build for production contains the package, not only your local development environment. A driver installed by hand into one running container is lost on the next rebuild.
The duckdb and duckdb-engine pair for MotherDuck
The database catalog lists both the duckdb and duckdb-engine packages for MotherDuck connections. Install them together and pin both to versions that match each other and your Superset release. A mismatch between the DuckDB engine and its Python driver often shows up as a failed connection or an error only when a query runs, so test a dashboard query after every image change, not only the connection dialog.
Outbound network access to MotherDuck
A MotherDuck connection is made from the Superset web and worker processes to the MotherDuck service, so those hosts need outbound access on the port and protocol the driver uses. Ask your network team to confirm that egress rules, proxies and DNS allow the connection from every node that runs Superset queries. Restricted networks often allow the Superset host to reach a database but block a cloud service, which makes a working local file connection look like a broken MotherDuck one.
File system access for local database files
A file-based DuckDB source is a path on the disk of the host that runs Superset, so every web and worker container must mount the same file or directory at the same path. Decide whether the file is read-only for dashboards, who writes to it, and how it is backed up. Confirm the Superset process user has read permission on the file and, if it writes, on the directory that holds the write-ahead file, and test this in the container, not on the host.
A MotherDuck account and access token
MotherDuck connections authenticate with a token passed in the connection string, so you need a MotherDuck account, the database name you will query and a token issued for that purpose. Confirm with MotherDuck which token types it offers, how long they remain valid and how to revoke one. Store the token in Superset's encrypted credential handling rather than in a dashboard or a shared document, and plan a rotation step before the token expires.
Data files and an access model
DuckDB reads CSV, Parquet and JSON files directly, so a Superset dataset can point at files that were never loaded into a database. Decide which files are approved sources, who owns their refresh, and which Superset roles can see the resulting tables. Because a DuckDB file can be copied or read by anyone with disk access, the file-level permissions and the Superset role model must agree, or the dashboards will expose more data than the users were meant to see.
Configuring the DuckDB or MotherDuck connection step by step
This sequence takes a self-hosted Superset from a clean image to a working DuckDB or MotherDuck data source, with a connection test and a sample query at each stage. Each check confirms the layer below it works before the next one is added.
Add the driver packages to the Superset image
Your platform or build engineer adds the duckdb-engine package to the Superset image, and adds the duckdb package as well when you plan to use MotherDuck. Install these at image build time, not inside a running container, so every web and worker pod gets the same driver. Confirm the packages are present by opening a shell in the running container and importing duckdb and duckdb_engine with Python. A clean import with no error means the driver layer is ready. Check the duckdb-engine release notes against the Superset version you run before pinning a version.
Choose the connection type for your data
Decide among three options before you write any connection string. A local file path such as duckdb:////path/to/duck.db suits a database file that lives on storage the Superset containers can read. An in-memory database suits ad hoc queries over files your query references directly, but it holds no persistent tables between sessions. A MotherDuck connection uses the duckdb:///md:{database}?motherduck_token={token} pattern and suits shared, cloud-hosted DuckDB databases. Record which option you chose and who owns the file or database, because that decision drives the storage, token and concurrency work in later steps.
Place the database file or Parquet data where Superset can read it
For a file-based connection, your infrastructure team mounts the DuckDB file or the directory of Parquet and CSV files into the Superset web and worker containers at the same path. Use a read-only mount for shared analytical files, and restrict write access to the team that refreshes them. Confirm the mount from inside each container by listing the path and opening the file with DuckDB. If web and worker pods see different paths, dashboards and alerts will fail in different ways, so check both.
Store the MotherDuck token outside the connection string
Create a MotherDuck token in your MotherDuck account and provide it to Superset through a secret your platform team manages, such as a Kubernetes secret or your container platform's secret store, rather than pasting it into a shared config file. Confirm with MotherDuck which token scope and expiry options your account offers, since these settings vary by account type and you should not assume them. Then confirm that the Superset connection can authenticate by running a test connection. A failed test with an authentication error points to the token value, not the driver.
Create the database connection in Superset
A Superset administrator opens the database connection settings, selects the DuckDB or MotherDuck option, and enters the connection string built in the earlier steps. Use Test connection before saving. A successful test confirms that Superset can load the driver and reach the file or MotherDuck database. Save the connection only after the test passes, and record the connection name, the owner and the data it exposes in your configuration notes.
Run a sample query over a Parquet or CSV file
In SQL Lab, run a short query that reads a known Parquet or CSV file through DuckDB, for example a count of rows or a select of a few columns with a limit. Compare the row count with the source file or a value your data owner has confirmed. A matching result shows that DuckDB can read the files and that Superset returns results from the connection. If the query fails on a path, check the mount from the earlier step before changing the connection string.
Add datasets and confirm the chart works
Add the tables or file-backed views you want analysts to use as datasets, then build one simple chart from a dataset. Check that the chart returns the same totals you saw in SQL Lab, and that the time column and filters behave as expected. Confirm that a user with the intended role can see the dataset and that a user without it cannot. This check closes the sequence, and it tells you whether the connection is ready for wider rollout or needs the concurrency review covered in the next section.
Why file paths and in-memory databases behave differently in Superset
A DuckDB file connection in Superset is a single-process database file on the Superset host, opened with a connection string such as duckdb:////path/to/duck.db. The file is not a network service. Every process that runs a query has to open that file from its own filesystem, so the path must resolve identically in the web container, every Celery worker that runs async queries, alerts and reports, and any scheduled task that touches the database. A path that works in the web container but is missing from a worker container will show up as a failure only when a chart is cached, exported or emailed. Before go-live, confirm the file is mounted at the same path in each container, that the Superset service user can read it, and that write access is granted only where a process actually needs to write.
An in-memory connection (duckdb:///:memory:) is a different thing. Its tables exist only while that connection is open, so nothing created in one query is visible to the next, and a restart or worker recycle erases everything. Superset's connection pooling and per-request connections make this worse, so in-memory databases are rarely useful for dashboards. Treat them as a way to test query syntax, not as a data source. If a dashboard depends on data you loaded earlier, that data needs to live in a file or in MotherDuck.
Parquet and CSV files are queried through DuckDB's own readers, usually in SQL that names the file with a function such as read_parquet or read_csv_auto. Those paths are resolved by the same process that runs the query, so the same mount rule applies to every data file, not only to the .db file. Ask whoever owns the data which files are the sources, where they are stored and how they are refreshed, and document that answer next to the connection. Confirm the exact reader functions and their behavior against the DuckDB version you deploy, since the Superset database catalog only states that DuckDB reads CSV, Parquet and JSON, and the database catalog does not describe file-level options.
Local files, in-memory or MotherDuck: which option fits
A single analyst exploring a dataset is the situation where DuckDB fits most naturally. A local .duckdb file or an in-memory database lets someone point Superset at a few Parquet or CSV files and build charts within a day, without provisioning shared storage or a managed account. The trade-off is that the database belongs to one machine and one process, so the dashboard exists only as long as that environment does.
- Ownership: the file or session lives on one workstation or one container, and the analyst is the only one who can refresh it.
- In-memory state: an in-memory database disappears when the process restarts, so anything loaded into it must be recreated by a script.
- Concurrency: an in-process engine is not designed to serve many dashboard users at once, so a prototype should not be shared widely.
- Data handling: copies of sensitive extracts on laptops create exposure that your data classification policy may not allow.
- Promotion path: plan the move to shared storage or MotherDuck before dashboards are used by others, not after.
Before you rely on a prototype, confirm where the file lives, who can read it, and whether the data may leave the workstation at all.",
When several people need the same dataset, the common pattern is a DuckDB file or a set of Parquet files on a volume that the Superset container can read. Superset then connects with a path-based URL such as duckdb:////path/to/duck.db. This keeps data under your control, but it moves responsibility for file locking, refresh timing, backups and volume permissions to your platform team.
- Mount design: the path in the connection string must exist inside the Superset container, so the volume mount is part of the configuration, not an afterthought.
- Write access: a single writer and many readers is the simpler model. Confirm how your DuckDB version handles concurrent access to one file before allowing writes from other processes.
- Refresh: someone must own the job that replaces or updates files, and dashboards will show stale data if that job fails silently.
- Backups: the file or directory is now production data, so it needs the same backup and restore testing as any other store.
- Scaling limits: the engine runs inside the Superset worker process, so heavy queries compete with the web application for memory and CPU.
Ask your platform team how the volume is mounted, who holds write permissions, and what recovery looks like if the file is corrupted.",
MotherDuck is a managed service built on DuckDB. Superset connects with a URL of the form duckdb:///md:{database}?motherduck_token={token}, which moves storage and query execution for shared data to the service rather than to your Superset host. The decision is less about performance than about where data is hosted, who operates the service, and how credentials are issued and rotated.
- Hosting decision: data stored in MotherDuck is hosted by a third party, so the data classification and residency review must happen before the first connection.
- Token handling: the token in the connection string is a credential. Store it in Superset's encrypted database configuration or a secrets manager, never in a dashboard export or a shared notebook.
- Token scope and rotation: confirm with the vendor how tokens are scoped, how long they last, and how you revoke one without breaking other dashboards.
- Network path: confirm that outbound connectivity from your Superset environment to the service is allowed under your egress rules.
- Cost model: the service bills under its own terms, so ask the vendor for current pricing rather than assuming it matches your existing database costs.
Before choosing this option, confirm the hosting terms, token lifecycle and egress requirements with the MotherDuck documentation and your security team.
Mapping datasets, files and MotherDuck databases to Superset objects
This table maps each DuckDB or MotherDuck source to the Superset objects that expose it, from database connection to dataset to role. Read it as a checklist: for every row, confirm who owns the object and where access is enforced. The main takeaway is that a DuckDB file has no per-user access model, so Superset roles, dataset definitions and row-level security must carry the entire access decision.
| Superset object | What it maps to | Who controls it | Where access is enforced |
|---|---|---|---|
| Database connection | One DuckDB file path or one MotherDuck database (md:{database}) | Platform team, through the connection string and token | Connection permissions in Superset; token scope in MotherDuck |
| Schema | A schema inside the DuckDB file or MotherDuck database | Data owner who builds the file or database | Only where the connection exposes it; Superset does not restrict it per user |
| Dataset | A table, view or Parquet or CSV read exposed as a queryable object | Analyst or data owner who defines the dataset SQL | Dataset-level permissions in Superset roles; no native per-user restriction in the file |
| Parquet or CSV source | Files read through DuckDB functions in a view or virtual dataset | Data engineer who maps file paths and schemas | Filesystem permissions on the host, plus the dataset that wraps the read |
| Superset role | A group of permissions covering specific databases and datasets | Superset administrator, mapped from the identity provider where used | Role grants on each database and dataset; reviewed before each release |
| Row-level security rule | A filter added to a dataset so each role sees only its rows | Data owner approves the rule; administrator applies it | Superset row-level security, because DuckDB cannot filter rows per user |
| MotherDuck token | A credential that scopes the MotherDuck session for one connection | Platform team creates and rotates it | Token scope and rotation in MotherDuck; storage in Superset secrets handling |
Concurrency limits of an in-process engine under dashboard load
DuckDB runs inside whatever process opens it, so Superset workers, dashboard users and background jobs all share one engine's locks and host resources. The cards below cover the failure modes to design around and the tests to run before you promise concurrent users.
Process-level engine sharing
A DuckDB database opened by Superset lives inside the process that opens it, not in a separate server. Each Gunicorn web worker, each Celery worker and any in-memory connection gets its own engine instance with its own memory and threads. Count the processes that will open the file, and size host CPU and RAM for their combined peak, not for one user's dashboard. Confirm the exact connection and threading behavior against current DuckDB documentation before you fix the worker count.
File write locking
DuckDB allows one writing process at a time on a database file, and readers in other processes can be blocked or refused while a writer holds the file. Superset itself only needs to read for charting, but any ETL job, dbt run or manual load that writes to the same file can stall dashboards. Keep write paths separate from the file Superset reads, or schedule writes in a window when dashboards are idle. Verify the current locking rules in the DuckDB documentation for your version.
Async queries and cache workers
Async queries, alerts, reports and thumbnails run in Celery workers, so the same DuckDB file may be opened from several worker processes at once. Each additional worker adds an engine instance and a potential lock contender, which changes how a slow query affects the rest of the queue. Decide which workloads run asynchronously and cap worker concurrency for the DuckDB connection specifically, rather than relying on the defaults set for a client-server warehouse.
Caching to reduce repeated scans
Superset's caching layer can answer repeated chart requests without reopening work against the engine, which matters more for an in-process engine because every query consumes the host's own CPU and memory. Set cache timeouts per dataset based on how often the underlying Parquet or CSV files change. Stale cache entries after a file refresh will show old numbers, so pair long timeouts with a refresh step that clears the cache for affected datasets.
Load tests before promising users
Build a test that mirrors your real dashboards: the number of charts per dashboard, the number of simultaneous viewers, filter changes and any scheduled reports running at the same time. Record query latency, lock wait errors, memory use per process and failed requests. Use the results to set a published user limit, and repeat the test after each Superset or DuckDB upgrade. Do not commit to a concurrency figure that has not been measured on the hardware you will run.
When to move to a server engine
If the load tests show lock waits, memory pressure or queueing that tuning cannot fix, the in-process model has reached its limit for that workload. The usual options are a client-server engine that Superset connects to over the network, or MotherDuck, which moves the query engine to a managed service and keeps the token-based connection model described on this page. Ask any vendor to confirm concurrency behavior in writing for your query pattern before you choose.
Common DuckDB and MotherDuck connection failures and fixes
This table lists the failures teams most often hit when Superset reads a DuckDB file or MotherDuck database, with the likely cause, the check to run and the fix for each. Work through the rows in order, since a missing driver or a wrong path will hide the later problems. The main takeaway is that most failures trace back to the image contents, the path as seen from inside the container, or the connection string.
| Failure | Likely cause | Check to run | Fix |
|---|---|---|---|
| Driver not found when testing the connection | The duckdb-engine package was not installed into the Superset image, so SQLAlchemy cannot load the duckdb dialect. | Open a shell in the running Superset container and confirm that duckdb and duckdb-engine import cleanly with Python. | Add duckdb-engine (and duckdb for MotherDuck) to the image build and redeploy. Do not install packages into a running container. |
| File path not found | The connection string uses a path on the host, not the path inside the container, or the file was never mounted. | Run ls on the exact path from the connection string inside the Superset container. Compare it with the volume mounts in the deployment. | Mount the file or directory into the container at the path used in the connection string, then update the string to match. Use an absolute path such as duckdb:////path/to/duck.db. |
| File lock error under concurrent queries | DuckDB allows a single writer per database file, and an in-process engine in several Superset workers can contend for the same file. | Check whether more than one worker process or a separate writer process holds the file open. Review the error text for lock or busy messages. | Open the file read-only where dashboards only read, limit concurrency for that connection, or serve the data from MotherDuck. Confirm the locking behavior for your DuckDB version with the DuckDB documentation. |
| Token rejected or expired | The MotherDuck token in the connection string is invalid, revoked, expired or copied with extra characters. | Test the token with a simple query from a client outside Superset. Confirm the token has not been rotated or revoked in the MotherDuck account. | Create a new token in MotherDuck, update the connection string or the secret store that feeds it, and retest. Confirm the token expiry policy with MotherDuck before setting a rotation schedule. |
| Wrong MotherDuck database name | The {database} segment in duckdb:///md:{database} does not match an existing MotherDuck database, or the name differs in case or spelling. | List the databases visible to the token from a MotherDuck client and compare the exact name. | Correct the database name in the connection string. Confirm that the token has access to that database. |
| In-memory data appears empty | An in-memory DuckDB connection starts with no tables, and each connection or worker can hold its own separate copy of the data. | Confirm whether the connection string points to in-memory storage and whether the tables were created in the same session that dashboards query. | Use a file-backed database or MotherDuck for data that dashboards must see. Treat in-memory mode as suitable only for temporary, per-session work that you can recreate. |
| Parquet or CSV files not found | The read_parquet or read_csv path is relative to the working directory of the container process, or the files are not mounted. | Run a simple read statement against the same path from the container shell, using the same user the Superset process runs as. | Use absolute paths in the SQL, mount the data directory read-only, and confirm the file permissions allow the Superset user to read them. |
| Permission denied on the database file | The file owner or mode does not allow the user that runs Superset to read or write it. | Compare the numeric user ID of the Superset process with the owner and mode of the file and its directory. | Adjust ownership or group membership on the mounted path, and grant read-only access where dashboards do not need writes. |
Questions teams ask before connecting DuckDB or MotherDuck to Superset
Can our internal team connect DuckDB or MotherDuck to Superset without a partner?
Yes, a team with Superset and Python experience can make the connection, but the hard parts are design decisions rather than the connection string itself. The connection uses the duckdb-engine package and a connection string such as duckdb:////path/to/duck.db for a local file, or duckdb:///md:{database}?motherduck_token={token} for MotherDuck. Your team still needs to decide where the database file lives, how the driver is installed into the Superset image, who owns the MotherDuck token, and how dashboards behave when several users query at once. Confirm with the DuckDB and MotherDuck documentation which driver versions they expect, and check whether your team has capacity to own the image build pipeline after go-live.
What drives the cost of a DuckDB or MotherDuck setup for Superset?
The cost depends on how many datasets, access rules and environments are involved, and on who performs each step. Cost components usually include discovery of the data sources, building the Superset image with the driver, configuring connections and permissions, testing with a representative dataset, and handing over documentation and runbooks. Recurring costs include image rebuilds when Superset or the driver changes, token rotation, and any support retainer you choose. Ask any provider, including DeployOpen, for a written scope that lists each of these items, the number of connections and dashboards included, and the environments covered. A quote follows from that written scope.
How long does a DuckDB or MotherDuck connection take to set up?
The duration depends mainly on the number of datasets, the complexity of row-level access rules, and how many environments you need before production. A single connection to one database file is a short task, while many datasets with per-team permissions take longer to model and test. Testing time also grows with the size and variety of the Parquet or CSV files you query. No general duration is supplied for this integration, so ask any provider to state the schedule in writing, tied to the dataset count, access model and staging requirements you define.
What do we need to provide before the work starts?
Plan to supply a representative test dataset, the list of Parquet, CSV or DuckDB files or MotherDuck databases that dashboards will use, and a named owner for each MotherDuck token. You also need access to the Superset environment where the image is built and deployed, and a build pipeline or registry where the image with the driver can be versioned. Decide who approves changes to access rules before the build starts. A test dataset should resemble production in size and column types so that query behavior can be checked before real users connect.
Who should own the MotherDuck token?
A named technical owner inside your organization should own the MotherDuck token, with a documented process to create, store, rotate and revoke it. The token appears inside the connection string, so it must be stored as a secret rather than as plain text in dashboards, shared notebooks or version control. Confirm with MotherDuck how tokens are scoped and how revocation works before you rely on them in production. Review who can edit the Superset database connection, because anyone with that permission can usually see or replace the token.
Why does a single in-process DuckDB file limit concurrent dashboard users?
DuckDB runs inside the process that opens the file, so concurrency depends on how Superset workers open and share that database. Many simultaneous dashboard queries can contend for the same file or compete for memory and CPU on the host running Superset. Plan for a small number of concurrent users, test with realistic dashboard loads, and check the DuckDB documentation for its concurrency model and file locking behavior. If many users query the same data at once, a server-based warehouse usually handles that load better, and you should confirm the limits of your chosen DuckDB version before committing to a design.
When is a server warehouse a better fit than DuckDB or MotherDuck?
A server warehouse fits better when many users need dashboards at the same time, when data volumes grow beyond what one host handles comfortably, or when several teams need separate governed access to shared tables. DuckDB and MotherDuck suit smaller analytical datasets, exploratory work and file-based sources such as Parquet and CSV. Compare the expected concurrency, data growth, access model and operating responsibilities of each option. Your Superset architecture also matters, since its metadata database and optional caching and worker components are separate from the analytics source, so the query engine choice should be made on its own merits.
What should we check with the image build and upgrades over time?
Check that the driver is installed in the same image you deploy, that its version works with your Superset release, and that each Superset upgrade is tested in staging before production. The upgrade guide asks you to back up the metadata database, run the database upgrade and initialization commands, and review UPDATING.md for breaking changes. Each new image should be rebuilt, tested against your DuckDB or MotherDuck connections, and recorded so you can roll back. Ask whoever builds the image to document which driver versions were tested with which Superset release.
When DuckDB or MotherDuck stops fitting Superset dashboards
A DuckDB file or a MotherDuck database fits Superset well while a small group of analysts builds dashboards against data they already trust. The point to watch is the moment that assumption stops holding. DuckDB runs in-process, so each connection opens the database file inside the Superset worker that serves the query, and the engine is designed for a single writer at a time. When many dashboard viewers refresh charts together, when more than one pipeline needs to write, or when Superset's async queries and scheduled reports pile up on the same file, you will see lock contention, slow refreshes and failed loads. Ask your team to measure peak concurrent queries against the file during a realistic dashboard review, and to note any database is locked style errors in the Superset and worker logs before you commit to the design.
Governance is the second signal. A file on a shared volume has no native role model, so access to the data is decided by who can read the file and by whatever row filters Superset applies on top. That works for a small internal audience but becomes hard to defend once auditors ask who saw which rows, who changed the data and how grants are reviewed. Check whether you need per-user or per-group data permissions that the database itself enforces, separate write paths for ingestion and reporting, and retention or audit logs for the data source. Those needs point toward a server engine, and the sibling integrations for Trino, ClickHouse and PostgreSQL cover those alternatives, each with its own driver, permission model and cost profile. Confirm the specifics of each engine with its vendor and with your own environment before choosing.
How DeployOpen scopes and delivers a Superset and DuckDB integration
DeployOpen treats the DuckDB or MotherDuck connection as one part of a self-hosted Superset deployment in your infrastructure. We start from which files, databases and users need to be queried, then design the driver, connection, token handling and access model around that. Each engagement is fixed-scope, with deliverables agreed in writing before work starts.
How we scope
- Inventory the DuckDB files, Parquet and CSV sources, and any MotherDuck databases that dashboards will query.
- Record where each file lives, who writes it, and whether Superset needs read-only or write access to it.
- Agree in writing whether the scope covers a local DuckDB file, an in-memory setup, MotherDuck, or a combination of them.
How we build
- Install the duckdb-engine package into the Superset image and confirm the connection string format for each source type.
- Store MotherDuck tokens in the secrets handling your organization already uses, not in dashboard or database settings visible to users.
- Test concurrent dashboard loads against the in-process engine to confirm the limits your team will live with before go-live.
How we hand over
- Document each connection, file path, token owner, rotation steps and the users or roles that can query each source.
- Provide a runbook for replacing or refreshing data files and for diagnosing failed queries or locked database files.
- Walk your platform and analytics teams through the deployment so they can operate the integration without us.
How we support
- Plan Superset upgrades and driver version checks so the duckdb-engine package stays compatible with each release.
- Review query limits and dashboard load as data volumes grow, and recommend when a file-based source should move to another engine.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
