Live data from Hacker News

Quack: The DuckDB Client-Server Protocol

duckdb.org

71–80 of 91 posts

Re: Quack: The DuckDB Client-Server Protocol

#71
post #19

Does this work with duckdb-wasm?

Although a maintainer answered you, watch the video from the blog. There's a WASM demo at the end, which is great. It also has a good explainer for those confused about the HTTP decision.

And I appreciate that the Hannes still appreciates the magic of the WASM. [And I keep hearing quark which makes me hungry for tangy creamy German yogurt]

Re: Quack: The DuckDB Client-Server Protocol

#72
post #28

Earlier quoted context omitted.

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…

SQLite isn't a moving target like DuckDB is. It's scope is very well defined. I'm not knocking Quack or DuckDB but I'm starting to get a bit confused.

But why though? DuckDB can still be used as a local query engine — I still use it as that. I haven’t touched any of the DuckLake stuff and the duckdb cli and Python library are still my bread and butter. They can add new use cases, but it doesn’t affect the core engine.

Is the concern that the duckdb messaging is now diluted by it having all these extra features? That you can’t sell it to friends as “this thing” like you can a one use tool like curl? I get that, but I also feel that duckdb is so much bigger than a “do one thing and do it well” tool.

It’s an engine that drives the modern data tool stack. Duckdb’s team has been prescient in that it has made many tasteful bets on what users want —- the ability to interop with pandas and polars, addition of geospatial, the plug-in infra. They’re all optional but when you neeed these things, they’re so useful. They’ve also clued me into what the broader data world is thinking about (I didn’t know about sketches and hilbert, but those are so useful in probailistic large scale queries and in geospatial queries). And they exist in larger database systems like Redshift too.

So far duckdb’s bets have been tasteful, and mostly ignorable if you don’t happen to use them.

Re: Quack: The DuckDB Client-Server Protocol

#73

> Can I use DuckDB with Quack as the catalog database for DuckLake? > Not yet, but we are working on it! Seems like a niche use case, but it's the one I'm most interested in. Our lakehouse uses ducklake with postgres as the catalog. Seems like a DuckDB / Quack catalog would be an excellent alternative.

Well, we are really working on it: https://github.com/duckdb/ducklake/pull/1151 So you'll be able to test it in a few days.

already works now! just tried it out

Re: Quack: The DuckDB Client-Server Protocol

#75
post #19

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 missed that and it seems like one of the more compelling features...!

Re: Quack: The DuckDB Client-Server Protocol

#76

Been working on open-source projects involving storing and querying observability data (metrics, logs, traces) in parquet[0] and have been frustrated with the usability of Apache Iceberg … despite strongly agreeing and wanting to use an open storage format and catalog. This makes Ducklake much more interesting for my use case, excited where this is going. [0] https://github.com/smithclay/duckdb-otlp

Are you using it to replace Mimir?

Re: Quack: The DuckDB Client-Server Protocol

#77

Earlier quoted context omitted.

DuckDB is more for analytics. I don’t think you’re going to find good options for a DB that can handle concurrent users without hosting it in some way server side. It’s certainly possible (think how some games create their own client servers for direct multiplayer) but honestly hosting Postgres or SQLite is ridiculously cheap, easy, and more importantly the standard approach to this issue.

IIRC SQLite is in-process and says in it's documentation that it is not a client-server database.

It’s not, but you could do something like https://litestream.io/ and just continuously replicate it to pretend to be multi-user

Re: Quack: The DuckDB Client-Server Protocol

#78
post #76

Been working on open-source projects involving storing and querying observability data (metrics, logs, traces) in parquet[0] and have been frustrated with the usability of Apache Iceberg … despite strongly agreeing and wanting to use an open storage format and catalog. This makes Ducklake much more interesting for my use case, excited where this is going. [0] https://github.com/smithclay/duckdb-otlp

Are you using it to replace Mimir?

Not yet.

That said… think duckdb/ducklake/quack could potentially be a future replacement for Mimir or Clickstack with way less operational complexity.

Re: Quack: The DuckDB Client-Server Protocol

#79
post #77

Earlier quoted context omitted.

IIRC SQLite is in-process and says in it's documentation that it is not a client-server database.

It’s not, but you could do something like https://litestream.io/ and just continuously replicate it to pretend to be multi-user

Does SQLite + replication have any advantages over client-server, for someone not already using SQLite?

Re: Quack: The DuckDB Client-Server Protocol

#80
post #35

Earlier quoted context omitted.

I think the term you want to search for is local-first.

My understanding is that Local First means syncs across multiple devices, which is not the same thing as multi-user concurrent access.

It's both. I recommend looking into it a bit deeper

https://www.inkandswitch.com/essay/local-first/

Post reply on HN