Choose DuckDB rather than SQLite | Hacker News Reader

Choose DuckDB rather than SQLite

tracewayapp.com

88 pointsrubenvanwyk57 comments

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).

Agreed. It felt like I was reading a chat with Claude Code.

Yeah I couldn't make it past the cliff title

This is AI slop, but I really want to know more about their write patterns and how they were doing batches.

> DuckDB's columnar engine

That is workload specific. Title should be "Choose DuckDB rather than SQLite for Analytics" IMHO

Yes - it's a specific workload for sure. SQLite is still the GOAT when it comes to OLTP, but DuckDB is really becoming the GOAT in the OLAP world - I think DuckDB is simply amazing and truly an amazing piece of technology for anyone working with large amounts of data.

> SQLite is still the GOAT when it comes to OLTP, but DuckDB is really becoming the GOAT in the OLAP world

Can you explain this more, especially why SQLite is best at OLTP and what happens at scale?

Most people forget that clickhouse embedded exists

Let's keep discussion bar high.

I've just checked their website, and they state "relying on ClickHouse to power these analytics use cases". That's not OLTP. https://clickhouse.com/comparison/postgresql

Fair to say, seeing 1000x w/o any trace of proof won't help me to choose.

You new to the world, right? ClickHouse proven being a beast for analytics, tracing and even some basic metrics storage (VM won of course, but still CH is probably 2nd or 3rd)

* for other readers, VM here most likely refer to Victoria Metrics

Every day someone is new to the world. Analytics is not OLTP. Would appreciate for anything to read except “you stupid” and “believe me, bro”.

This. The title might as well be “Choose a hammer rather than a wrench (when driving nails)”

Yeah, someone who has more tokens than simple sense.

DuckDB also implements MVCC. In DuckLake, the DB is used for absorbing small writes and compacting them before sending to object storage.

It has some characteristics typical of OLTP engines. But they are targeted and limited to areas DuckDB feels are important.

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

Quack is now kind of a workaround for that limitation, as you can have a process with the lock offer read access to other processes. It's not perfect, but for that specific use case it's pretty good.

Duckdb has a server mode[1] which might alleviate some of those pain points. SQLite is a bit more precise in that only a single connection can write to the DB which provides more concurrency but still has pain points. For a single file DB either choice seems justifiable to manage complexity.

[1]: https://duckdb.org/2026/05/12/quack-remote-protocol

You can have multiple read only processes. But yes, concurrent read mode and write mode is blocked

This is actually the biggest reason I don't automatically choose sqlite for small project databases. I've built a lot of toy utilities that crossed a bare threshold of usefulness, and then suddenly it's not a toy anymore when people start using it.

Now it's debt. Oops.

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.

SQLite is _the_ tool of choice for local SQL databases with minimal overhead. If you needed a single file DB for an OLAP workload, SQLite was still the best option even if the technology wasn't an ideal fit. Duckdb is exciting specifically because SQLite/duckdb aren't comparable; we can stop shoehorning OLAP into an OLTP database.

I ran into this myself; I tried using SQLite to store the results of whole-internet rDNS scan and a count() over the entire DB could take 8 minutes. I used the wrong DB for the job and the narrative around SQLite/duckdb is around reckoning with perfectly reasonable limitations and tradeoffs that SQLite made.

Sure, but this is what I'm getting at. :) SQLite is a general-purpose engine that is absolutely amazing at what it does and where it's used (and in many cases even where it isn't appropriate). But TFA was about comparing the two which just doesn't work because one is hand-tuned for a specific use-case while the other is not.

With indexes SQLite is very very fast even for aggregation at medium scales.

And DuckDB is reasonably fast for even single record writes. ~1000x slower than SQLite, but that's still pretty fast if you're only doing a few hundred writes per second or batching.

Agreed. And DuckDB certainly has a very nice API. But I wouldn't use it for a general dataset (think document storage).

Title, which is already synthetic, should be "Choose DuckDB rather than SQLite for Analytics Workloads".

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

This is a bait and switch article. Compare apples and oranges, "oh btw look at our product".

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.

> $16.49/month server [...] hetzner CCX13

That server is now $51.09 for those wondering See https://news.ycombinator.com/item?id=48540844

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.

Wait seriously? That's a dealbreaker if true.

I don’t use it myself but a friend of mine uses it at a startup selling a cheap snowflake proxy and yeah, especially with new releases.

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.

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)

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!

Heartening to see so many "This is an apple, that is an orange" comments. Spot on folks!

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 ?

Do you think venture capital firms are made of money?

Yes? They certainly act like they are...

well played sir. well played.

AI comments aren't allowed on HN. AI submissions are.

It would still be nice to mark them.

Yes, I am asking if that particular policy could be changed. A little AI here and there is fine, to each their own, but I would prefer not to read posts that are overwhelmingly so.

It's one thing for us to detect and autokill generated comments on our own site; it's our site and we can set the rules and run software on our own servers to process the comments and handle things in the way we and the community are happy with.

It's a big additional leap to for our software to try to reach into others' sites, get through any anti-bot defenses they may be running, try to scrape their content and evaluate on whether it's sufficiently human-authored to be on HN.

There's generally a wider range of LLM involvement with a long-form post than the typical, relatively brief HN comment, which then opens the way for more debate on HN about "how much" LLM influence the post has and how much should be allowed on HN. Part of what we're trying to optimize for on HN is minimizing offtopic/meta discussion, so we don't want to encourage this kind of debate.

Our heuristic about article quality is largely unchanged from before LLMs were an issue: if an article is badly written, it shouldn't be on HN, and should be flagged.

There are AI-detection tools which exist. Even if those won't run against all URLs, using them where possible should provide some utility. HN already penalises sites based on various criteria, and if it takes hand-pasting some examples from a site to find that it is/isn't using AI slop, that's another option.

As to what should be tested: front-page items, possibly even a subset of those (top 10--15 of 30). That's going to be a limited set of items per day, though more than just 30. (I don't know how many items cycle through the front page on a daily basis, though I believe daily submissions as of 2022 were about 1,000/day (<https://web.archive.org/web/20220116193045/https://whaly.io/...>)).

Working this into the HN story-processing lifecycle might be a good call.

I'd much prefer not seeing a bunch of AI slop in submissions, by way of generated output. AI as part of the resarch process I think I could live with.

AI-generated content seems, definitionally, not to be intellectual in nature, and would seem to go against HN's prime directive. It also seems to make HN lose its collective mind, which has long been another mod consideration.

You should talk with dang, as the email I received about this from him, to my eyes, does not agree with your stance here in the long term. I don’t want to get into the interminable blood quantum debate over Llm authorship either, however, I see substack doing something about it, and, as a long time hn reader, it makes me want to spend more time over there than here.

We're talking about it all the time :) My comment above doesn't contradict the email. I didn't say we're not wanting/planning to do anything about it, just that there's more to it than plugging in Pangram. If Substack is being more proactive about it on their own site, that's great. It would make life easier for all of us if all the major content platforms cleaned up their own sites. We're already proactive about detecting/autokilling genai comments posted to our own site. It's detecting genai content on 3rd party sites that introduces more complications.

In the meantime, please feel free to flag items that are badly written/unpleasant to read, and email us if something is on the front page that shouldn't be there.

Looking forward to seeing how you handle it! I understand the complications of it as an engineer, I hope you figure out something soon!

And shouldn't be.

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.

You could use the framework built-in sqlite, or you could drop in h2 and use that. It's much more advanced than sqlite.

Even for row-based data?

How about writing with sqlite and querying with duckdb-sqlite, using a replica or WAL, to avoid locks?

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.

wait, it means you should not save all traces to Langfuse? what is the primary usecase of Langfuse? exporting some subset of all traces for some quality checks etc.?

great research there

Reply on news.ycombinator.com