可以。DuckDB 是 in-process（嵌入應用程式行程內）的分析資料庫，能直接用 SQL 查 CSV、Parquet，也支援讀取 .xlsx；不必先架一台資料庫 server。它特別適合多個本機檔案的 adhoc 分析與跨檔 JOIN，但不是 nightly ETL、多人共用權限或企業數倉的替代品。
什麼是 in-process analytical database？
傳統 client-server 資料庫需要一個長期運行的 server，使用者透過網路連線。DuckDB 則可嵌入 CLI、Python 或桌面應用，在同一個 process 內執行分析查詢。對使用者而言，優勢是少了 server 安裝、帳號與連線管理，仍保留 SQL 的 filter、JOIN、aggregation 與 window function。
它不是「把 CSV 變成正式數倉」，而是讓檔案立刻成為可查詢的來源。依 DuckDB CSV 文件，最簡單的查法是：
SELECT *
FROM 'orders.csv'
LIMIT 20;
CSV 沒有固定 schema，DuckDB 會抽樣推斷格式與型別；重要分析仍應檢查推斷結果，必要時明確設定欄位型別、分隔符或 sample size。
從資料夾、Excel 到 JOIN 的三個例子
一次讀取一整個月份資料夾
DuckDB 支援 glob，可把多個同 schema 的 CSV 當成一張表：
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 會按欄名對齊不同檔案，缺少的欄位補 NULL。這很方便，但也可能掩蓋上游 schema drift；正式執行前應列出檔案來源與缺欄比例。DuckDB 多檔案文件 提供 glob、檔案清單與 filename 欄位的完整用法。
查 Excel 指定工作表
DuckDB Excel 文件 的 .xlsx 範例是：
SELECT *
FROM read_xlsx('targets.xlsx', sheet = 'Q3 Targets');
官方 DuckDB read_xlsx 不支援舊 .xls。產品若宣稱支援 .xls，通常代表它另外做了轉換或載入層，不能把該能力直接算在原生 DuckDB 上。
把本機目標和訂單 JOIN
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);
這比手動 VLOOKUP 更容易保留計算邏輯；但仍要先確認兩邊 region 是否唯一、命名是否一致，否則 JOIN 可能重複放大。
DuckDB 最適合的四種人
- Excel 重度使用者：檔案已多到公式與複製貼上難以重跑，但還不需要建數倉。
- 營運與分析師：常收到多個 CSV／Parquet，要快速合併、聚合與驗證。
- 工程師與研究者：需要在本機或 notebook 直接查檔案，不想先把資料載入 server。
- 小團隊試點：要先證明指標與資料價值，再決定是否投入正式 pipeline。
判斷方式很簡單：如果問題是「我桌面上有十個資料檔，今天要得到可重跑的答案」，DuckDB 通常很合適。
什麼時候不該只靠 DuckDB？
如果需求是多人同時存取、中央身份與 row-level 權限、穩定 nightly ETL、持續服務 dashboard、資料品質 SLA 或跨區備援，應評估資料倉庫、lakehouse、orchestrator 與 BI。DuckDB 可以是其中的查詢或開發元件，但單一 in-process 工作環境不會自動提供完整平台能力。
另外，直接讀檔代表結果依賴檔案版本與路徑。檔案被覆蓋後，相同 SQL 不一定得到相同結果；需要稽核時要保存來源版本、更新時間、SQL 與限制。
Lantide Data 把 DuckDB 變成可審閱的分析工作面
Lantide Data 內建統一 DuckDB 查詢層，使用者與 Agent 共用相同 SQL 管線。工作區可載入 CSV、TSV、JSON／JSONL、Parquet，以及 .xls／.xlsx 工作表；後者是 Lantide 的載入能力，不等同 DuckDB 原生 read_xlsx 支援 .xls。也可 ATTACH PostgreSQL、MySQL、SQLite，讓本機檔與外部表跨源 JOIN。完整格式見 使用者指南 §1.5。
持久 SQL 分頁執行後可產生暫存快取，後續 SQL 以分頁名引用；有上游依賴時可用 Source Run 按順序重跑並查看 lineage。這些快取在切換工作區或重啟後會清除，因此是分析中間結果，不是 durable warehouse table。詳見 快取與 Source Run 與 統一查詢層。
若讓 Agent 參與正式分析，Lantide 的價值不是「AI 直接給一個數字」，而是先把分母、grain、JOIN 與 checkpoint 寫進 Plan，由人核准 Execute，再把 SQL evidence 與 Report 留下。它仍不代替資料 owner 對口徑與品質的判斷。
結語
先拿兩個 CSV 或一份 .xlsx 做小實驗：用 SQL 完成 preview、group by 與一個 JOIN，並把查詢存下來。如果需求開始出現固定排程、多人共享與權限 SLA，再把穩定邏輯搬到正式資料平台；在那之前，DuckDB 能大幅降低「只是想查檔案卻先要架系統」的門檻。