· duckdb / sqlite / database

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 · 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:

DatabaseVersionReleased
DuckDB1.5.3May 20, 2026
SQLite3.53.1May 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.

WorkloadDuckDBSQLiteRatio
Direction ID scan (~850k rows, GTFS 35M-row table)2.90 ms2,722 msDuckDB 938× faster
Route ID scan (~63 rows avg, GTFS)7.70 ms182 msDuckDB 23.6× faster

Transactional lookups: SQLite wins

Flip the workload to indexed point lookups and the story reverses completely.

WorkloadSQLiteDuckDBRatio
Primary key lookup0.063 ms0.927 msSQLite 14.7× faster
Composite key lookup0.078 ms9.68 msSQLite 124× faster
Indexed join0.118 ms13.3 msSQLite 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.

PlanPrice
Free10 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