Ask HN: Who's using DuckDB in production?
4 points
12 hours ago
| 1 comment
| HN
Inspired by the post that's on the front page as I write this [1] I'm interested to hear about who's using DuckDB in production and how.

We have a tool live that uses it and I'm quite happy so I'm both looking for interesting use cases from others but also to be honest I'm reasonably sure I've just identified today that DuckDB is leaking memory quite seriously [2] so I'm curious to hear if other people have noticed this or if it's maybe something that's not as relevant to others since people might be running DuckDB pipelines in ephemeral envs like lambdas etc. where a memory leak might not matter as much.

[1] https://news.ycombinator.com/item?id=46645176

[2] https://github.com/duckdb/duckdb/issues/20569

delaminator
12 hours ago
[-]
This is expected behaviour, not a bug.

DuckDB (like most database systems and many applications using memory allocators like jemalloc or mimalloc) doesn't immediately release memory back to the OS after freeing it internally.

Memory allocator strategy - DuckDB uses an allocator that keeps freed memory in a pool for reuse. Returning memory to the OS is expensive (system calls, page table updates), so allocators hold onto it anticipating future allocations.

reply
yakkomajuri
11 hours ago
[-]
Also the docs say that dropping tables should free their memory:

"Running DROP TABLE should free the memory used by the table"

Source: https://duckdb.org/docs/stable/sql/statements/drop

reply
yakkomajuri
12 hours ago
[-]
Thanks for explaining this! I suspected there was some additional context and was digging into it now. Problem is that the memory never seems to be freed, and I could update my issue to show this.

Maintainers have acknowledged problems like this on other issues too.

But I'll nevertheless read more into this!

reply
delaminator
10 hours ago
[-]
tbh i might dig a bit deeper as it reports zero memory use itself.
reply