Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • DuckDB is really neat, recently added PDO interface for it for PHP https://github.com/iliaal/pdo_duckdb

    Still a bit raw, but getting there

  • I'm just curious - is duckdb too slow for people? This benchmark from clickhouse shows it being fairly slow compared to some options: https://jsonbench.com/
  • Hi, DuckDB engineer here, to tackle this problem of efficiently storing and querying semi-structured data (aka JSON), we've put in a lot of work into the VARIANT type and still continue to pour a lot more work into it regularly, so expect to see some developments on this area in the upcoming major release!
  • That's for their `JSON` data types. In DuckDB it's just a string meaning lots of queries will have to do JSON parsing on every row, but the inserts are very fast. Definitely a bit of a footgun and when you actually just need STRUCT or MAP.

    There's a talk about ClickHouse's approach from its creator: https://www.youtube.com/watch?v=xHj9mysh0GI , but the gist is that it maintains (sub)columns to store different paths in the JSON

    In other ways DuckDB has very good JSON support, like you can do `CREATE TABLE name AS `SELECT * FROM 'data.json';` and it'll infer the schema when possible.

  • I hope it will not go to the same path like MySQL or other Open source software bought and to the graveyard!
  • The one huge caveat for anyone that cannot use dynamic linking e.g. in an AppStore context, DuckDB isn’t a great choice. It’s very hard to statically link extensions.

    This is where Arrow wins I think. Arrow CPP for example has very portable builds and the C interface is very usable for building bindings.

    DuckDB is excellent, but it’s more a black box than a library.

    Edit: after a conversation with a robot, it would seem that the DuckDB and ArrowCPP C APIs are complimentary, so it's very possible to have Arrow CPP and DuckDB to coexist in an app, each with its own strength. Arrow CPP doen't have a simple SQL story for example.

  • I can't confirm this, I have several instances which have statically linked extensions...
  • It's an interesting project, but the discussion on HN looks weird. It gets brought up every few weeks[1] and everyone just spams comments with messages about how "fast" it is.

    DuckDB is fast for some specific workloads. If you use it for most other things, it is at least an order of magnitude slower than SQLite. It also has some limitations in terms of what SQL it will currently run (e.g. I immediately ran into an issue with recursive queries). That will probably get better with time.

    [1] If you search HN for "sqlite" and "duckdb" you get 4,310 hits and 2,398 hits respectively. That's a very heavy skew, considering SQLite is everywhere and had been around for a quarter century, while DuckDB effectively appeared on the scene two years ago.

  • > DuckDB effectively appeared on the scene two years ago

    I don't think so.

  • I’m sure the use of duckdb may seem weird for normal developers, but for data people it really is game-changing, especially for data scientists or business analysts.
  • The article has an explanation for what kind of database it is. After reading that one sentence you wouldn't write the second paragraph.

    > it's optimized for the kind of queries that scan millions of rows to filter, aggregate, and join — not the kind that look up a single record by primary key

  • > while DuckDB effectively appeared on the scene two years ago.

    duckdb is ~7 years old by now. it was quite popular long before it became 1.0. heck, even motherduck has been founded 4 years ago.

  • > DuckDB is fast for some specific workloads

    Yes, it's specifically promoted as DBMS for OLAP workload. And it's usually compared to ClickHouse, another analytical DBMS. So people who use it know why it's good.

  • I'm going to sound like a broken record but... different use cases. They're analogous in the comparison "sqlite for analytics" but completely different architectures and implementations. Part of this is the fault of the developers, but I feel they were trying to highlight the similar focus on in-process, zero dependencies, simplicity and test coverage - not a direct "vs" comparison. IME recursive queries in analytical workflows are not very common; they typically work against the fundamental data layout on disk.

    SQLite is awesome and I would love to see more posts about it, but the reality is one of the major reasons it's awesome is the no-drama/stability/it just works. DuckDB is seeing a lot of development on many fronts so there's a lot more to learn and talk about right now.

  • The data scientists I work with use this. Why do they use it? I don't really know much about it, but I've noticed they use it quite often. I mainly use MySQL or PostgreSQL. What are the advantages of DuckDB? It seems like they usually use it as an alternative to Pandas.
  • Primarily the ability to work directly with data in its native format (CSV for example) without needing ETL.
  • Here is the thing, it’s a write only single file format. If you need to run analytical queries it’s optimized for reading, you just open a file and query for the parts you want. If you have multiple clients that read and write data to the database, you should use postgresql.

    It’s not really a database in the traditional sense, there is no ACID complexity, it’s a library that lets use write SQL to query a tabular data file.

  • DuckDB has been probably my most used tool in 2026 - if you're comfortable with SQL it's incredible at quickly prototyping and slicing / dicing data.

    I do a lot of experiments with regexes, and if you get used to the RE2 syntax that DuckDB uses, you can see up to 10-100x uplift in terms of speed compared to Postgres on things like regexp_matches(), regexp_extract(), etc (depending on query/table/machine specifics). It has quite powerful scripting with custom Macros, fixes a lot of annoyances of SQL for me compared to Postgres.

    I think if you have access to a machine with a lot of RAM / cores and a beefy data set, then it's basically like a RAMdisk version of Snowflake running locally on your machine.

    (and of course the fact that it makes it convenient to read CSV/parquet, read/write from S3, etc) - it's a very ergonomic tool.

  • > DuckDB has received widespread adoption because it's just so damn easy to use.

    This was a major factor in my initial adoption. Since then it has stuck because it’s also absurdly capable, versatile, and fast.

    If it wasn’t so easy to use I suspect I wouldn’t have adopted it when I did. The ergonomics are crazy. It still impresses me regularly.

  • What do you use it for? I’m perpetually interested in using DuckDB, but it doesn’t seem to do anything I need.
  • DuckDb makes so much of my life easier, though I've never used it for large problems. The ability to run `select * from 'data.json'` is just lovely. The fact that it's also a powerhouse is so impressive, I'd usually expect a project to be good at small problems (like mine) xor large problems, but not both
  • Yup. And an extra benefit that you can treat any file like a table, so you can also do something like

      UPDATE my_table
      SET x = file1.x,
          y = file2.y
      FROM 'first_file.csv' file1
      LEFT JOIN 's3://my_bucket/second_file.parquet' file2
        ON file1.id = file2.id
      WHERE mytable.id = file1.id;
  • If you're reading this and curious: consider writing a duckdb community extension* or contributing to an existing one*

    duckdb is becoming a kind of data superglue between a lot of data ecosystems (GIS, observability, analytics, lakehouses, object storage, etc) that don't talk to each other typically, and it's worth checking out in 2026.

    * https://github.com/duckdb/extension-template * https://duckdb.org/community_extensions/

  • Just curious whether one can earn money making these exts?
  • DuckDB is amazing, especially extensions.
  • I just started doing this last week!

    I'm not very good at C++, but coupled with the extension template and codex I got a basic version of my extension working within an hour. Go for it!

  • I have a database on my local machine with 200 million records in one table and 2 other related tables. Even the most complex queries take about 1 minute to vibe code and paste into the DuckDB browser playground UI and always less than 5 seconds to return the result. For a humble product manager it feels like a superpower.
  • DuckDB is amazing for any sort of fast data analysis when the data is small enough that it can fit on your laptop

    Recently at work I've been using it to analyse the Claude code sessions of every engineer at our company (that we upload to S3) and it's been extremely helpful to help us find gaps in devex and have clear metrics to back up the impact of fixing them

    Another thing it's been really useful for has been getting metrics on Claude skills usage and then dive into use-cases by looking at the transcripts

    Other engineers that had never touched DuckDB were so impressed with how easy it is for AI agents to write queries on our dataset

  • >DuckDB is amazing for any sort of fast data analysis when the data is small enough that it can fit on your laptop

    It also works great for data that doesn't fit on my laptop.

  • Can you please expand more on the claude analysis part. What exactly you analysed and what outcome it helped with ?