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.

▲

wenc an hour ago | parent | next [-]

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, your desktop apps, iot devices and people have extended it in different directions. The only difference here is that this is first party not third party. But to me it’s a very legible move.

▲

2 hours ago | parent | prev | next [-]

[deleted]

▲

whalesalad 3 hours ago | parent | prev | next [-]

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.

	▲	duzer65657 2 hours ago \| parent [-]
		this is a great use-case for duckdb, but not sure how it maps to the use of this protocol?

▲

slotix 2 hours ago | parent | prev | next [-]

I read it less as "DuckDB wants to become Postgres" and more as DuckDB becoming an execution layer inside bigger workflows.

The engine is often not the painful part anymore. The pain is the stuff around it: live DBs, S3 paths, Parquet files, credentials, repeatable runs, exports, validation, and the moment a one-off script quietly becomes infrastructure.

Quack makes the remote/server part cleaner, but the bigger trend seems to be DuckDB becoming the SQL layer inside tools, not necessarily the final user-facing tool.

▲

Lemaxoxo 3 hours ago | parent | prev [-]

I can't think of many use cases for this and Arrow Flight, other than moving data around.

▲

twoodfin 3 hours ago | parent | next [-]

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?

▲

szarnyasg 3 hours ago | parent [-]

Hello, DuckDB DevRel here. Quack is independent from MotherDuck. MotherDuck has its own proprietary protocol, which has been around for years and it supports things like dual execution – see more here:

https://duckdb.org/quack/faq#what-is-the-relationship-betwee...

Of course, in the future MotherDuck can also support Quack, but this is not the only interesting use case for Quack.

	▲	twoodfin 3 hours ago \| parent [-]
		Sure! Not knocking the architecture: Building out peer-to-peer federation in place of client/server makes perfect sense for DuckDB. And I’m a big fan of owning the protocol so you can optimize it to internal structures. Just making the point that DuckDB is disruptive technology & what it’s most likely to disrupt.

▲

jtbaker 3 hours ago | parent | prev [-]

uh, doing analytics type queries on large datasets that postgres would choke on, as an RPC? I'm using it (ducklake specifically) to build a lakehouse RPC server that can scale horizontally based on resource utilization in k8s.

▲

Lemaxoxo 2 hours ago | parent [-]

Right, I get that usecase. You have to crunch numbers that sit somewhere, and store the outputs in the same place. DuckLake is great for that. But where does this DuckDB client-server setup fit in?

	▲	jtbaker an hour ago \| parent [-]
		Sounds like it means you don't have to wire up the RPC server yourself anymore? Just build a docker container that invokes this quack server command, expose it over the network and connect to it from remote clients using your own access controls? Ducklake handles the metadata and storage, but a local duckdb instance connected to it still has to do the compute itself. This lets you federate access to the compute. Fun for me, I just finished a big streaming implementation doing essentially the same thing in Go-gRPC with arrow table record batches. It was fun though.