Live data from Hacker News

Choose DuckDB rather than SQLite

tracewayapp.com

31–40 of 65 posts

Re: Choose DuckDB rather than SQLite

#31
post #23

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

Re: Choose DuckDB rather than SQLite

#32
post #18

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…

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.

Re: Choose DuckDB rather than SQLite

#34
post #12

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 ?

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

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.

Re: Choose DuckDB rather than SQLite

#37

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…

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

Re: Choose DuckDB rather than SQLite

#39
post #15

Earlier quoted context omitted.

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
Post reply on HN