Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Quack: The DuckDB Client-Server Protocol

duckdb.org

Post reply on HN
Print view View original

11–20 of 91 posts

Re: Quack: The DuckDB Client-Server Protocol

#12

Post by duzer65657 »

whalesalad wrote: post #6
simlevesque wrote: post #2

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.

Our data pipeline produces .duckdb files that our app downloads (it watches the asset in S3 and pulls when etag changes). Makes it easy to get BQ/Clickhouse like performance without running or paying for that infrastructure. Not perfect for all cases, but it handles a lot more than you would expect.

this is a great use-case for duckdb, but not sure how it maps to the use of this protocol?

Re: Quack: The DuckDB Client-Server Protocol

#14

Post by duzer65657 »

ozgrakkurt wrote: post #9

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

Re: Quack: The DuckDB Client-Server Protocol

#15

Post by mritchie712 »

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

Re: Quack: The DuckDB Client-Server Protocol

#16

Post by arpinum »

NortySpock wrote: post #5

Sounds useful for small-ball internal analytics datasets you want to place on shared team server. I can definitely see exploring this for some homelab use.

With ducklake this scales well to multi-terabyte data sets. The big benefit of this server protocol is sharing a high memory server and taking advantage of a shared cache for recent data.

Re: Quack: The DuckDB Client-Server Protocol

#17

Post by szarnyasg »

mritchie712 wrote: post #15

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

Re: Quack: The DuckDB Client-Server Protocol

#18

Post by arpinum »

ozgrakkurt wrote: post #9

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

It uses http/2, it has streaming.
Post reply on HN