[goerch]

That sounds like a rather serious application. Did you file an issue?

[andrewstuart]

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]

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

[goerch]

Understood: SQLite is to Postgres as DuckDB is to ClickHouse.

[andrewstuart]

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

[ciupicri]

I 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]

Agree 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`.

[andriy_koval]

I filed many issues. They were aurtoclosed after 3 months of inactivity