They didn't explain what "concurrent writers" is. But seems it's just serialized writes on server side.
Quack: The DuckDB Client-Server Protocol
61–70 of 91 posts
Re: Quack: The DuckDB Client-Server Protocol
#62Re: Quack: The DuckDB Client-Server Protocol
#63I 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…
Re: Quack: The DuckDB Client-Server Protocol
#64Earlier 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.
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
#65Re: Quack: The DuckDB Client-Server Protocol
#66I 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…
Re: Quack: The DuckDB Client-Server Protocol
#67Earlier 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…
Re: Quack: The DuckDB Client-Server Protocol
#68I 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
#69I 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…
Re: Quack: The DuckDB Client-Server Protocol
#70Earlier 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.