3 ms·
No, I tried Clickhouse instead, which worked without crashing or manual memory tuning. Search the issues of the duckdb GitHub there’s at least 110 open and clo
by andrewstuart 6mo ago
No, I tried Clickhouse instead, which worked without crashing or manual memory tuning.
Search the issues of the duckdb GitHub there’s at least 110 open and closed oom (out of memory) and maybe 400 to 500 that reference “memory”.
- goerch 6mo agoUnderstood: SQLite is to Postgres as DuckDB is to ClickHouse.
- andrewstuart 6mo agoI don’t see the analogy, if you’re using it to excuse crashing on small data sets and indexes. SQLite isn’t small and crashy, it’s small and reliable. There’s something fundamentally wrong with the codebase/architecture if there’s so many memory problems. And the absolute baseline requirement for a production database is no crashes.
- goerch 6mo agoAgree with your assessment of small and reliable for SQLite. Disagree with your baseline requirement. ACID is more important for me and does not contain `No crashes`.
- ciupicri 6mo agoI think the authors disagree with me, but I see it like a online analytical processing (OLAP) database, not like a OLTP (online transaction processing) database, so crashes are more tolerable.
- goerch 6mo ago> Search the issues of the duckdb GitHub there’s at least 110 open and closed oom (out of memory) and maybe 400 to 500 that reference “memory”. Ah, missed this the first time around. Will check this out. And yes, I noticed that DuckDB rather aggressively tries to use the resources of your computer.