Yes, you can. DuckDB is an in-process analytical database that can query CSV and Parquet directly and can also read .xlsx files, without first running a database server. It is especially useful for ad hoc analysis across multiple local files and cross-file JOINs, but it is not a replacement for nightly ETL, shared permissions, or an enterprise data warehouse.
What is an in-process analytical database?
A traditional client-server database requires a long-running server reached over a network. DuckDB can instead be embedded in a CLI, Python process, or desktop app and run analytical queries in that same process. Users avoid server installation, accounts, and connection administration while keeping SQL filters, JOINs, aggregations, and window functions.
It does not "turn CSV into a production warehouse." It makes files immediately queryable. The simplest form in the DuckDB CSV documentation is:
SELECT *
FROM 'orders.csv'
LIMIT 20;
Because CSV has no fixed schema, DuckDB samples data to infer format and types. Important analyses should inspect that inference and explicitly set types, delimiters, or sample size when needed.
Three examples: folders, Excel, and JOINs
Read a whole month of files at once
DuckDB supports globs, so several CSV files with the same schema can behave like one table:
SELECT region, sum(amount) AS revenue
FROM read_csv('exports/2026-06/*.csv', union_by_name = true)
GROUP BY region
ORDER BY revenue DESC;
union_by_name = true aligns files by column name and fills missing columns with NULL. That is convenient, but it can hide upstream schema drift. Before formal execution, list the source files and the rate of missing columns. The DuckDB multiple-files documentation covers globs, file lists, and the filename column.
Query a specific Excel worksheet
The .xlsx example in the DuckDB Excel guide is:
SELECT *
FROM read_xlsx('targets.xlsx', sheet = 'Q3 Targets');
DuckDB's native read_xlsx does not support the older .xls format. When a product supports .xls, it usually provides a separate conversion or loading layer; that capability should not be attributed to native DuckDB.
JOIN local targets with orders
WITH targets AS (
SELECT * FROM read_xlsx('targets.xlsx', sheet = 'Q3 Targets')
), actuals AS (
SELECT region, sum(amount) AS revenue
FROM 'orders/*.parquet'
GROUP BY region
)
SELECT
t.region,
t.target,
a.revenue,
a.revenue / NULLIF(t.target, 0) AS attainment
FROM targets t
LEFT JOIN actuals a USING (region);
This preserves the calculation more clearly than manual VLOOKUP operations. You still need to confirm that region is unique and named consistently on both sides, or the JOIN may multiply values.
Four groups that benefit most from DuckDB
- Heavy Excel users: files have outgrown formulas and copy-paste workflows, but a warehouse is not yet justified.
- Operations teams and analysts: they regularly receive multiple CSV or Parquet files that must be combined, aggregated, and validated quickly.
- Engineers and researchers: they need to query files locally or in notebooks without loading them into a server first.
- Small-team pilots: they want to prove a metric and the data's value before investing in a production pipeline.
A useful rule of thumb is: if the problem is "I have ten data files on my desktop and need a rerunnable answer today," DuckDB is usually a good fit.
When should DuckDB not be the only tool?
If you need concurrent multi-user access, centralized identity and row-level security, dependable nightly ETL, continuously served dashboards, data-quality SLAs, or cross-region recovery, evaluate a warehouse, lakehouse, orchestrator, and BI platform. DuckDB can be a query or development component, but one in-process workspace does not supply a complete data platform.
Direct file access also makes results depend on file versions and paths. The same SQL may return a different result after a file is overwritten. For auditability, preserve source versions, update times, SQL, and limitations.
Lantide Data turns DuckDB into a reviewable analytics workspace
Lantide Data includes a unified DuckDB query layer shared by users and Agents. A workspace can load CSV, TSV, JSON/JSONL, Parquet, and .xls/.xlsx worksheets. The Excel support is a Lantide loading capability and does not mean native DuckDB read_xlsx supports .xls. You can also ATTACH PostgreSQL, MySQL, and SQLite to JOIN local files with external tables. See User Guide §1.5 for supported formats.
Running a persistent SQL tab can create a temporary cache referenced by later SQL using the tab name. When upstream dependencies exist, Source Run can rerun them in order and show lineage. These caches are cleared when switching workspaces or restarting, so they are analytical intermediate results, not durable warehouse tables. See Cache and Source Run and the Unified Query Layer.
When an Agent participates in formal analysis, Lantide's value is not that "AI returns a number." The Plan first states the denominator, grain, JOINs, and checkpoints. A person approves Execute, after which SQL evidence and a Report remain available for review. Data owners still decide definitions and quality.
Conclusion
Start with two CSV files or one .xlsx: use SQL to preview, group, and JOIN, then save the query. If the work begins to require fixed schedules, shared access, and permission SLAs, move stable logic into a production data platform. Until then, DuckDB sharply reduces the setup required to simply query a file.