41.1k stars · MIT · v1.5.5 (2026-07-22) · Track this in Scout
SQL over three years of price bars in a file, with no server and no import step.
▶Repo detailsthe review · specs · pros & cons
What it is
An in-process analytical database — SQLite's shape, but built for scanning and aggregating columns rather than fetching individual rows. It queries CSV, Parquet and pandas DataFrames directly inside your Python process, with no server, no daemon and no loading step.
What it is good for. Two slow problems are often the same problem. A research project with three years of one-minute price bars has pandas re-reading and re-filtering them on every experiment, while a research.db steadily accumulates yt-dlp metadata, comments, transcripts and Reddit pulls that SQLite will eventually be slow to aggregate. DuckDB answers both: SELECT ... FROM 'bars_*.parquet' returns in about a second on data larger than RAM, and it will attach and query an existing SQLite file in place without a migration. The practical effect is that you stop waiting on your own data, which is what determines how many experiments you are actually willing to run.
- MIT, one
pip install, no server and no daemon — nothing new to back up beyond the files that already exist. - Reads Parquet and CSV directly, so there is no ETL ceremony between having data and asking it a question.
- Attaches SQLite and Postgres, so it sits beside an existing stack rather than asking to replace any of it.
- It is an analytical engine, not a replacement for the Postgres behind an application — concurrent writes are explicitly not its job.
- Storage-format stability has improved but still moves between majors; pin the version and keep the source files.
- One more SQL dialect's small differences to learn, which mostly bite in date handling.
