[flagged]
Quack: The DuckDB Client-Server Protocol
51–60 of 91 posts
Re: Quack: The DuckDB Client-Server Protocol
#52> 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?
no we don't (source: work at motherduck)
Re: Quack: The DuckDB Client-Server Protocol
#53They didn't explain what "concurrent writers" is. But seems it's just serialized writes on server side.
Re: Quack: The DuckDB Client-Server Protocol
#54Been 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.
Re: Quack: The DuckDB Client-Server Protocol
#55Earlier quoted context omitted.
They mention in the benchmarks section that the network they're on is a "up to" 15 Gbps connection. So to max out 50GB/s is not realistic. I agree they should have also listed the compressed size of the table instead of only mentioning the CSV size. But the compressed dataset is probably not smaller than 1/10 of the CSV size. If that's the case they're transferring ~8GB in 4.6 s on a 2GB/s (15Gbps) connection. Seems…
That makes sense. I meant to write 50gbps, I don’t mean they should reach that, I mean you could use any protocol that is fairly efficient and it would reach that. The size of the dataset should be under 3GB in parquet from what I understand. [0] So it did 3*8/4.94 = 4.85 Gbps which is underwhelming in terms of network performance. It is still not possible to make any conclusions since we don’t know how specifically…
Agreed, that does seem a bit underwhelming. Hopefully there are some performance gains to be made before the production release in september.
Re: Quack: The DuckDB Client-Server Protocol
#56cool
Re: Quack: The DuckDB Client-Server Protocol
#57I 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.
Just find the one that is right for you.
Re: Quack: The DuckDB Client-Server Protocol
#58> 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…
They also wanted the protocol to work with duckdb wasm in the browser. I can’t comment on the performance side but that consistency piece is pretty key to duckdbs value proposition I think.
Re: Quack: The DuckDB Client-Server Protocol
#59I 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…
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.
Re: Quack: The DuckDB Client-Server Protocol
#60I 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…
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.