Comments 1
Код для Pandas в статье не заработает из-за неверных аргументов, правильно так:
engine='pyarrow', dtype_backend='pyarrow'
В целом вывод статьи о том что скорость современных либ примерно равна - верный. Примерно такую же скорость покажет и SQLite (in-memory). Но более медленный бэкендnumpy/python хоронить рано, он поддерживает кое-что недоступное в pyarrow
В ряде строковых отборов/фильтраций numpy/python в ~2-4 раза быстрее всех остальных способов. Помимо DuckDB - чистый SQL применим и в Pandas. Вообще знание SQL на хорошем уровне - не повод не изучить Pandas, потому что индексация для решейпинга таблиц и джойнов всего со всем - в Pandas очень развиты и они гибче чем SQL. Соотношение объема кода больших запросов Pandas vs SQL примерно 1:4, и это повод задуматься тем, кто ищет инструмент лучше чем SQL. При этом часто логично использовать SQL для "первичной" выборки, а Pandas - для "уточняющей" и решейпинга результата. Потому что оконные функции SQL гораздо сложнее чем UDF на Python в стиле df.col.apply(UDF).
Со временем у аналитика нарабатывается пара сотен UDF для своего предметно-ориентированного EDA/ETL, они попадают в либу, и переиспользование кода становится удобным. Сравнивать с хранимками в SQL бесполезно: полная интроспекция, докстринги и перезагрузка - всё это в Python удобнее.
Преобразование табличных данных в Python