Choose DuckDB rather than SQLite
tracewayapp.com
Choose DuckDB rather than SQLite
1–10 of 65 posts
Re: Choose DuckDB rather than SQLite
#2[deleted]
Re: Choose DuckDB rather than SQLite
#3Even for row-based data?
Re: Choose DuckDB rather than SQLite
#4[flagged]
Re: Choose DuckDB rather than SQLite
#5> DuckDB's columnar engine
That is workload specific. Title should be "Choose DuckDB rather than SQLite for Analytics" IMHO
Re: Choose DuckDB rather than SQLite
#6great research there
Re: Choose DuckDB rather than SQLite
#7TL;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.
Re: Choose DuckDB rather than SQLite
#8I 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 ?
Re: Choose DuckDB rather than SQLite
#9Too 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.
Re: Choose DuckDB rather than SQLite
#10[dead]