Live data from Hacker News

Quack: The DuckDB Client-Server Protocol

duckdb.org

61–70 of 91 posts

Re: Quack: The DuckDB Client-Server Protocol

#61

They didn't explain what "concurrent writers" is. But seems it's just serialized writes on server side.

I don't think that's correct. DuckDB already supports concurrent writes within one process. I don't see why this would suddenly serialize all writes.

Re: Quack: The DuckDB Client-Server Protocol

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

That is a pretty amazing feature.

Re: Quack: The DuckDB Client-Server Protocol

#63
post #28

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…

If SQLite added a protocol and client/server code to talk to other SQLites, it might get similar questions.

Re: Quack: The DuckDB Client-Server Protocol

#64

Earlier quoted context omitted.

https://firebirdsql.org has been flying under the radar in-between SQLite and full-blown PostgreSQL for decades, but if you're asking which client-server database to use PostgreSQL is the default recommendation.

Did some reading. Given my modest performance requirements, Firebird might be a good choice due to simpler install and admin. Thanks.

If postgres is too heavyweight for you but you still want client-server, I'd consider MySql. It's an old classic, pretty fast and scalable, and has much better mainstream support and a bigger ecosystem than Firebird.

I'm not really sure what Firebird is for at this point in life really. It was pretty exciting when it was open sourced in the early 2000s, before postgres became the mature beast it is, before mysql acquired something as basic as transactions, and before sqlite became the default embedded db. But then it never really went anywhere.

Re: Quack: The DuckDB Client-Server Protocol

#66

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…

Sounds like a good use case for CRDTs, which would also enable offline editing

Re: Quack: The DuckDB Client-Server Protocol

#67

Earlier quoted context omitted.

Did some reading. Given my modest performance requirements, Firebird might be a good choice due to simpler install and admin. Thanks.

If postgres is too heavyweight for you but you still want client-server, I'd consider MySql. It's an old classic, pretty fast and scalable, and has much better mainstream support and a bigger ecosystem than Firebird. I'm not really sure what Firebird is for at this point in life really. It was pretty exciting when it was open sourced in the early 2000s, before postgres became the mature beast it is, before mysql acqu…

Good to know. Thanks.

Re: Quack: The DuckDB Client-Server Protocol

#68

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…

Sounds like a good use case for CRDTs, which would also enable offline editing

In my use case I have 2 or 3 users editing the same database concurrently and they all want to see other's updates in near real time (within a second or two). Would a CRDT support that? It would be great if it did and I could just keep using XML to persist everything with no server. But that sounds unlikely.

Re: Quack: The DuckDB Client-Server Protocol

#69

I was just wishing something like this existed last week. What timing. 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 proble…

Can you expand more on how you use it in your workflows? I'm very interested but I haven't incorporated it into my problem solving mindset yet so I don't even know what use cases I could map to it.

Re: Quack: The DuckDB Client-Server Protocol

#70
post #4

Earlier quoted context omitted.

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?

MotherDuck is very expensive.

Compared to what exactly? Snowflake? Hiring an engineer to deploy DuckDB? A hobby project? FWIW I work at MotherDuck so obviously biased, but curious to hear what makes you say that.
Post reply on HN