Choose DuckDB rather than SQLite
rubenvanwyk
85 points
52 comments
July 29, 2026
Related Discussions
Found 5 related stories in 336.4ms across 15,380 title embeddings via pgvector HNSW
- DuckDB 1.5.2 – SQL database that runs on laptop, server, in the browser janandonly · 151 pts · April 22, 2026 · 75% similar
- DuckDB 1.5.0 erikcw · 15 pts · March 10, 2026 · 72% similar
- Announcing DuckDB 1.5.0 bluehat974 · 13 pts · March 09, 2026 · 67% similar
- Distributed DuckDB Instance citguru · 169 pts · April 14, 2026 · 62% similar
- Full-Text Search with DuckDB ethagnawl · 111 pts · April 30, 2026 · 58% similar
Discussion Highlights (20 comments)
pixelesque
Even for row-based data?
brightball
> DuckDB's columnar engine That is workload specific. Title should be "Choose DuckDB rather than SQLite for Analytics" IMHO
sharpvik
great research there
egeozcan
TL;DR: SQLite was doing OLAP work it was never built for (and it was okay at it, I must add), and the perf. ceiling moves two orders of magnitude when you use something that's more fit for the purpose (DuckDB in this case). TLDRTL;DR: If everything you do is column-store territory, use a column-store.
knuckleheads
I ran this through an AI checker and it flagged half of it immediately. @dang, I know Substack just enabled Pangram integration, is there anyway you could get Y Combinator to spring for a Pangram subscription for the front page or something ?
clumsysmurf
Too bad Android doesn't have JDBC APIs. Getting the native binaries compiled on Android is the easy part, but there is no straightforward way to access it from Java. The Room APIs are tied to SQLite as well.
cynicalsecurity
Great job on comparing apples to oranges. DuckDB is a columnar OLAP engine, SQLite is row-oriented OLTP. DuckDB should stomp SQLite in that particular use case.
tptacek
Title, which is already synthetic, should be "Choose DuckDB rather than SQLite for Analytics Workloads".
otterley
AI slop. The content might be valuable but the framing makes it too painful to read. Please, folks, write with your own voice -- especially if it's for your business blog . It's good for you as an author (practice makes perfect) and it's good for your readers (whom you want to influence).
ethin
How are these two DB engines even comparable other than at the edges? They handle two completely separate workload types: one is more a general-purpose DB engine and the other is specifically for columnar datasets, analytics and the like -- of course a hand-tuned DB engine is going to destroy SQLite on any reasonable benchmark: SQLite wouldn't be optimized for that hand-tuned use-case whereas something like DuckDB is.
shubhamjain
Despite its obvious advantages, the biggest drawback of DuckDB is its concurrency model [1]. If a process opens a database in read-write mode, it acquires an exclusive lock on the file. This prevents even simple read operations from other processes as long as the writer remains open. Maybe there's a simple workaround I haven't come across, but I found it to be quite a productivity killer. So yes, all these benchmarks are great, but it wasn't so fun working with DuckDB when I had to close duckdb cli, just so a query in another script could run. [1]: https://duckdb.org/docs/current/connect/concurrency
oathvz
This is a bait and switch article. Compare apples and oranges, "oh btw look at our product".
datadrivenangel
This is AI slop, but I really want to know more about their write patterns and how they were doing batches.
lanstin
DuckDB is modern but written in C++ and crashes in production more than SQLite, which is old and it doesn’t really crash. you have to build in resilience to use DuckDb.
raro11
> $16.49/month server [...] hetzner CCX13 That server is now $51.09 for those wondering See https://news.ycombinator.com/item?id=48540844
crustycoder
Heartening to see so many "This is an apple, that is an orange" comments. Spot on folks!
k3liutZu
I couldn't read the article as it read like AI. And I am fatigued by the AI style in all code comments, reviews, PRs etc :(
biophysboy
As many others have said here, you should just think about transactional vs analytical as well as single user in-process vs multi-user client-server when making choices. That said, I do think duckdb has a wider range of use cases than people here might think. It can whip through fairly large datasets (I use it for ~1B row tables all the time)
d1l
The AI slop is tiring man wtf. It’s so fucking lazy. The benchmark is comparing apples to oranges and doesn’t seem to be aware of it, and the way it’s written just reeks of LLM.
adsharma
SQLite can be replicated. rqlite, dqlite, litestream etc DuckDB can't be. PR was sent a year ago. Blocked on the same concurrency model issue in the other sub thread. Specifically on windows, the database can't read its own WAL file from a different thread in the same process. Love DuckDB for being permissively open source, great tech and performance!