41–50 of 91 posts
I like DuckDB but I'm not sure what it wants to be. There's always new ways to use it and it's not easy to see what's the right one.
+1 I can't think of many use cases for this and Arrow Flight, other than moving data around.
Does this work with duckdb-wasm?
It's in the article: > HTTP also allows the DuckDB-Wasm distribution to speak Quack natively! So DuckDB running in a browser can e.g., directly connect to a DuckDB instance running in an EC2 server using Quack.
I'm piping sensor readings into duckdb with a deno server, and couldn't use duckdb -ui to look over the data without shutting down the server. I had no interest in using the server to allow me to look at the contents of the db, so I was just going to live with it for now. This perfectly solves that, along with several other similar kinds of problems I've encountered with duckdb.
duckdb is my favourite technology of 2025/26. It has worked its way into so many of my workflows. It's integral to how I work with LLMs, how I store all kinds of data, analytics, data pipelines... I love it.
I have a C++ application. Everything is in memory during execution. Saved to disk between session as XML. Works great, except that that it is strictly single user and some of my customers would love me to generalize it for multiple concurrent users reading and writing. Performance requirements are quite low - a few thousand records being updated by 2 or 3 people at a time. Would DuckDb + Quack be a good choice for th…
> It would be rather misguided not to build a database protocol on top of HTTP in 2026 This is wrong, HTTP is bad for transferring large amount of data and it is also bad for doing streaming. It is bad for large amount of data because you have timeout issues on some clients, you hit request/response size limits etc. It is obviously bad for streaming as there is no concept of streaming in it. It is comical to go the p…
really like duckdb and sorry to pile on, but the parent makes some strong points. I wonder if MotherDuck builds on http as well?
Earlier quoted context omitted.
+1 I can't think of many use cases for this and Arrow Flight, other than moving data around.
The use case is local user DuckDB talking to MotherDuck for $. This is not commercially a terrible idea. Why keep paying Snowflake for bog-standard SQL query workload when SF makes it easy to migrate to Iceberg & commodity engines like MotherDuck?
I like DuckDB but I'm not sure what it wants to be. There's always new ways to use it and it's not easy to see what's the right one.
DuckDB is both a standalone and a component. This effort is actually very coherent and brings it back into a familiar usage model — that of a traditional client server RDBMS. RDBMS have always been multi-user concurrent systems. DuckDB is a very fast local engine that has a multitude of use cases because it is a embeddable in other systems. It’s like saying what does SQLite wanna be? It’s in your phones, your browser…
I'm not knocking Quack or DuckDB but I'm starting to get a bit confused.