There is a specific frustration in data work that DuckDB solves so completely that people become evangelists about it. You have a file. It is large. You want to answer a question about it.
The available options were loading the whole thing into memory with pandas and hoping, or standing up a database and importing it, and both are disproportionate to the size of the question. DuckDB lets you write SQL directly against the file, without a server, without an import step, and it is very fast. The documentation gets you there quickly, which is the first thing in its favour. Install, open a connection, point a query at a file path, get results.
No configuration, no server process, no credentials, no schema definition. For a tool whose main selling point is removing friction, having documentation that itself has no friction is the right instinct and a surprising number of projects fail at it. The file format material is the practically important part. Reading Parquet, CSV, JSON and several other formats directly, including globbing across many files at once and reading remote files over HTTP or from object storage, all documented with examples you can copy and run.
The CSV handling deserves specific mention because CSV files in the real world are badly formed in creative ways, and the documentation on type inference, delimiter detection and how to override both when the sniffer gets it wrong is genuinely useful. The SQL dialect documentation is a pleasure, which is not a word I use about SQL references often. DuckDB has added a set of extensions aimed at the actual ergonomics of analytical queries. Selecting columns by pattern instead of listing forty of them.
Excluding or replacing specific columns from a wildcard. Sensible list and struct handling. Better grouping syntax. Each of these is documented with a before and after that shows why it exists, and the cumulative effect on query readability is larger than any individual feature suggests.
The Python integration is documented well and it is where most people will use this. Querying a pandas data frame directly with SQL, getting results back as a data frame or an Arrow table, moving between the two worlds without an explicit conversion step. The zero copy story with Arrow is explained clearly enough to understand why it is fast rather than merely being told that it is. The tone throughout is direct.
Short pages, real examples, no marketing, honest about limitations where they come up. Reading this after wading through the documentation of a large commercial data platform is a noticeable relief. Now the criticisms. It assumes SQL.
This is a reasonable assumption for a database and it means someone learning analytics from scratch cannot start here. They need to learn SQL somewhere else first and then come back, and the documentation does not point them anywhere. A single line linking to a decent SQL tutorial would help a lot of people. Memory behaviour deserves better coverage.
DuckDB can process datasets larger than available memory by spilling to disk, and how well that works depends on the operation, the query and the configuration. The documentation touches on this and does not give you a clear model of what will work, what will be slow and what will fail. Given that the main reason to reach for this tool is a file too big for pandas, the boundary of what it handles gracefully is exactly what a new user needs to know. The extension ecosystem is uneven.
Extensions add support for other file formats, spatial data, full text search and connections to other systems, and the documentation quality varies considerably between them. The core is excellent and some of the extensions feel like an afterthought. There is very little on when not to use this. It is an analytical database designed for read heavy queries by a single process.
It is not built for many concurrent writers, not a transactional store, and not a replacement for a warehouse where multiple teams need shared access with governance. Those boundaries exist and the documentation could be clearer about them, because enthusiastic people will try to use this for things it was not designed for. Pace of development is high, which is good for the tool and bad for anything written about it. Blog posts and tutorials from a couple of years back describe missing features and worse performance.
Prefer the official documentation and check the version notes, because the answer to whether it can do something has often changed to yes. My four point three is for concise, honest, well written documentation for a tool that genuinely improves the daily experience of working with data, marked down for assuming a SQL foundation without pointing anywhere to get it, for a vague account of the memory limits that matter most, and for extension coverage that does not match the standard of the core. This is one of the better things to happen to local data analysis in years and the documentation does it justice.