DuckDB vs SQLite: Which Wins for Desktop Analytics?
For any query touching more than a few thousand rows, DuckDB wins by a wide margin. SQLite still owns app persistence and indexed lookups. When to use each.
By Ethan · Updated May 25, 2026
962 words · 5 min read
For any query that touches more than a few thousand rows, DuckDB is the right answer. SQLite wins only when you are already using it for app persistence and do not want another dependency.
Who this is for
Data engineers, analysts, and Python developers choosing a local database for analytical workloads in 2026. If you are building an app with small, fast lookups — mobile, browser, embedded — stop here: SQLite is your answer and this article will not change your mind.
Version pins
All findings below are specific to:
| Database | Version | Released |
|---|---|---|
| DuckDB | 1.5.3 | May 20, 2026 |
| SQLite | 3.53.1 | May 5, 2026 |
Benchmark figures cited from Lukas Barth’s SQLite vs DuckDB benchmark (DuckDB v0.9.1 at time of writing — current DuckDB is faster, so treat the numbers as a conservative floor, not a ceiling).
Query performance
Analytical queries: DuckDB by an order of magnitude
DuckDB is a columnar engine designed for OLAP. SQLite is a row-store designed for transactional workloads. When you throw a full-table scan or aggregation at each of them, the difference is not close.
| Workload | DuckDB | SQLite | Ratio |
|---|---|---|---|
| Direction ID scan (~850k rows, GTFS 35M-row table) | 2.90 ms | 2,722 ms | DuckDB 938× faster |
| Route ID scan (~63 rows avg, GTFS) | 7.70 ms | 182 ms | DuckDB 23.6× faster |
Transactional lookups: SQLite wins
Flip the workload to indexed point lookups and the story reverses completely.
| Workload | SQLite | DuckDB | Ratio |
|---|---|---|---|
| Primary key lookup | 0.063 ms | 0.927 ms | SQLite 14.7× faster |
| Composite key lookup | 0.078 ms | 9.68 ms | SQLite 124× faster |
| Indexed join | 0.118 ms | 13.3 ms | SQLite 112.7× faster |
DuckDB is not built for low-latency point queries. Its per-query overhead is higher because it compiles a query plan, parallelises execution, and pays the setup cost every time. That is worth it on aggregations; it is not worth it when you already know the row address.
Python ecosystem
DuckDB’s Python integration is the reason most data engineers reach for it today.
import duckdb
import pandas as pd
df = pd.read_csv("events.csv")
# query the dataframe directly — no import step
result = duckdb.sql("SELECT user_id, COUNT(*) FROM df GROUP BY user_id").df()
You can also return Polars or Arrow without copying:
# returns a Polars DataFrame via Arrow
polars_df = duckdb.sql("SELECT * FROM df WHERE amount > 100").pl()
SQLite requires a round-trip through pd.to_sql() first. There is no native Arrow support. For ad-hoc analytics on DataFrames, DuckDB is the clear default.
File format support
DuckDB reads Parquet, CSV, JSON, Arrow, Delta, and Iceberg natively — no import step, no intermediate table.
# query a Parquet file on disk without loading it first
duckdb.sql("SELECT * FROM 'events.parquet' WHERE ts > '2026-01-01'").show()
SQLite uses its own proprietary format. Every other format requires explicit import. If your data lives in Parquet or comes from an Arrow pipeline, DuckDB cuts a lot of friction.
Cloud scaling
DuckDB is the engine behind MotherDuck, which lets you run the same DuckDB queries against cloud storage without rewriting anything.
| Plan | Price |
|---|---|
| Free | 10 GB storage + 10 compute-hours/month |
| Business | $250/month base |
Source: MotherDuck pricing
SQLite has no first-party cloud offering. Third-party options — Turso, LiteFS, SQLite Cloud — exist but they are separate products with separate APIs and separate trade-offs. None of them offer the “same code, runs in the cloud” path that MotherDuck does.
No affiliate programs exist for DuckDB, SQLite, or MotherDuck.
DuckDB and SQLite Adoption
DuckDB: 30K GitHub stars (June 2025), ~41M monthly PyPI downloads (May 2026), 3.3% Stack Overflow 2025 Developer Survey respondents use it, DB-Engines #42.
SQLite: billions of deployments in every smartphone, browser, and OS. No meaningful competitor for embedded storage.
They are not competing for the same space in practice — DuckDB’s growth is happening in the analytics layer, not at the expense of SQLite’s embedded use cases.
If your analytical workloads are pushing beyond a single machine, ClickHouse vs Postgres for analytics covers column-oriented databases built for 100M+ row datasets.
Verdict
Pick DuckDB if:
- You are running analytics, aggregations, or joins on more than 10K rows
- You work in Python with pandas, Polars, or Arrow
- Your data lives in Parquet, CSV, or JSON and you want to query it without an import step
- You want a path to cloud scaling via MotherDuck
Pick SQLite if:
- You are building app persistence, a mobile backend, or browser storage
- You need fast indexed lookups on small-to-medium datasets
- You are already using SQLite and do not want another dependency
- Minimal binary size matters (~600 KB vs ~5 MB)
For readers outgrowing SQLite and evaluating traditional relational options, Postgres vs MySQL 2026 covers the most common alternatives for app persistence.
Caveats
The benchmark numbers cited above use DuckDB v0.9.1 (Lukas Barth, 2024). DuckDB has released multiple major versions since then. Current DuckDB 1.5.3 is faster on analytical workloads; the SQLite point-lookup advantage on indexed queries is structural and unlikely to change. Treat all ratios as directionally correct but potentially understating DuckDB’s current analytical advantage.
References
- DuckDB 1.5.3 release notes
- DuckDB 1.5.0 release notes
- DuckDB 30K GitHub stars
- SQLite changelog
- Lukas Barth: SQLite vs DuckDB benchmark
- MotherDuck: DuckDB vs SQLite
- MotherDuck Python quickstart (part 2)
- DuckDB Polars docs
- KDnuggets 1M-row benchmark
- Stack Overflow Developer Survey 2025 — databases section
- DB-Engines: DuckDB system profile