Hacker News Reader

Comment by skybrian | Hacker News Reader

I wonder how terrible would it be to use DuckDB as the main database (running transactions) for a small project?

You might be able to make transactions work but it's really the opposite of what duckdb is designed for. Do it only for fun.

As long as its a single writer, you can get pretty far

"if you have worked with analytical systems in the past, you may assume that DuckDB cannot handle transactional workloads. But DuckDB has been built as a transactional, multi-connection database with full MVCC and transaction isolation since day one. Most users just never needed that in a single-user scenario. It turns out DuckDB handles transactions well: it's fast enough to compete with general-purpose databases like PostgreSQL on quite a few workloads, and the client/server pattern finally lets that machinery shine in multi-tenant, long-running deployments."

https://duckdb.org/2026/08/17/duckdb-20-highlights

Is there a guide on this anywhere?

Does anyone have any links to benchmarks or stories of attempting this in practice? (Even what their internal benchmark that lead them to say "it's fast enough to compete with general-purpose databases like PostgreSQL on quite a few workloads" was?)

https://duckdb.org/2026/05/12/quack-remote-protocol#benchmar...

The DuckDB devs measured it ~30x faster than PostgreSQL (and ~3x faster than Arrow Flight) for bulk transfer, which pg is known to be very slow at, and a bit faster (<2x) than pg for small writes up to 8 threads, after which they say that pg continues to scale well with number of threads but DuckDB plateaus.

single writer AND single reader.

https://duckdb.org/docs/2.0/connect/concurrency

We're doing this now...

https://github.com/shreeve/duckdb-harbor

Reply on news.ycombinator.com