Why DuckDB changes local analysis

Traditional databases such as PostgreSQL or MySQL run as servers, and they are designed for many small transactions: insert this order, update that account. Analytical work is different. You scan many rows, a few columns at a time, and aggregate them.

DuckDB is built for that analytical pattern, and it runs in process. When you start the duckdb command or import duckdb in Python, the whole database engine runs right there. No server, no network, no user accounts.

What makes it fast

• Columnar storage and execution: it reads only the columns a query needs and processes them in batches called vectors.
• Parallelism: it uses all your CPU cores automatically.
• Out of core processing: when data does not fit in memory, it spills to disk instead of crashing, so you can process files larger than your RAM.
• Direct file access: it reads Parquet, CSV and JSON files where they sit, using Parquet statistics to skip data it does not need.

When to use it

DuckDB is excellent for exploring files, prototyping transformations, running reports on a laptop, testing SQL that will later run in a warehouse, and powering small internal tools. It is not designed to be the database behind a busy web application with many concurrent writers. That is still a job for PostgreSQL or similar.

Install

# Command line client on macOS
brew install duckdb

# Python package (any platform)
python -m pip install duckdb

Installers for Windows and Linux are on the official site. Start the client with duckdb for an in memory session, or duckdb trips.duckdb to create or open a database file.

Your first query on a file

SELECT count(*) FROM 'trips_2026_01.parquet';

That is the whole thing. No CREATE TABLE, no import step. DuckDB recognises the file type from the extension and queries it directly. In the next lesson we look at what you can do with whole folders of files and messy CSVs.