Polars 개발팀은 2026년 10월 6일 Python Polars 2.0을 정식 출시했다. 공식 저장소에도 Python Polars 2.0.0 릴리스가 공개됐다. 이번 버전은 연산을 모아 나중에 실행하는 LazyFrame의 기본 처리 엔진을 기존 인메모리 방식에서 스트리밍 방식으로 바꿨다. Python에서 Polars로 데이터를 처리하는 사용자는 같은 코드라도 실행 방식이 달라질 수 있다는 점을 확인해야 한다.
메모리를 넘는 데이터를 디스크로 내보내는 처리도 기본 활성화됐다. 다만 출시 시점에는 지원 연산이 제한돼 있으며, 스트리밍 엔진의 일부 연산은 결과 행의 순서를 보장하지 않는다. 이번 업데이트를 적용할 때는 새 기능의 지원 범위와 함께 기존 코드가 기대하던 결과 순서, 사용하는 API가 유지되는지를 점검할 필요가 있다.
Default Engine
공식 이행 문서에 따르면 LazyFrame의 collect와 collect_async에서 기본값인 engine="auto"는 이제 스트리밍 엔진을 선택한다. 실행을 미뤄 둔 연산을 실제 결과로 만드는 단계의 기본 동작이 바뀐 것이다.
일반적인 eager DataFrame 연산, 즉 연산을 바로 실행하는 방식에서는 auto가 기존처럼 인메모리 엔진을 선택한다. 업그레이드 영향을 살필 때는 사용하는 코드가 LazyFrame의 지연 실행인지, 일반 DataFrame의 즉시 실행인지 먼저 구분해야 한다.
스트리밍 엔진은 일부 join, group_by, unpivot 연산에서 행 순서를 보장하지 않는다. 각각 데이터 결합, 그룹별 집계, 열을 행으로 펼치는 작업에 쓰이는 연산이다. 기존 순서에 의존하는 코드는 명시적으로 정렬하거나, 해당 연산이 지원하는 maintain_order 옵션을 지정해야 한다.
Disk and Query Features
메모리를 넘는 데이터를 디스크로 내보내 처리하는 기능은 ‘out-of-core’로 불린다. Polars 2.0에서는 이 기능이 기본 활성화됐으며, 약 80%의 RAM 사용량에서 디스크로 데이터를 넘기기 시작한다. 기본 디스크 예산은 64GB다. 대용량 작업에서는 메모리뿐 아니라 디스크 사용 조건도 살펴야 한다.
출시 시점의 지원 대상은 정렬, 윈도 함수, 여러 표현식이다. 개발팀은 join과 group_by의 out-of-core 지원을 향후 계획으로 제시했다. 따라서 스트리밍 엔진이 기본이라는 이유만으로 모든 연산이 메모리를 넘어 디스크에서 처리될 수 있다고 기대해서는 안 된다.
SQL 지원도 확대됐다. 조인 재정렬, 공통 하위 계획 제거, 동적 조건과 블룸 필터 등과 관련한 최적화가 강화됐다. 조인 재정렬은 데이터를 결합하는 실행 순서를 조정하고, 공통 하위 계획 제거는 중복되는 하위 실행 계획을 없애는 방식이다. 개별 작업의 성능 개선 폭은 이번 발표만으로 단정하기 어렵다.
Changes from Previous Versions
이전에는 LazyFrame의 collect와 collect_async가 auto 설정에서 인메모리 엔진을 선택했다. 2.0에서는 이 기본 선택이 바뀌므로, 엔진을 직접 지정하지 않았던 코드도 이행 점검 대상이 된다. 특히 결과의 행 순서를 전제로 후속 처리를 하는 경우에는 순서 보장 조건을 확인해야 한다.
자료형 처리에도 변화가 있다. 새 Map 자료형은 Arrow의 MapType을 직접 표현한다. 이전에는 같은 데이터를 키와 값으로 구성된 구조체의 리스트로 읽었다. 해당 형식을 다루는 사용자는 자료형을 확인하고 처리하는 코드가 새 표현과 맞는지 점검할 필요가 있다.
성능 측정용 LazyFrame.profile()은 제거됐다. 공식 이행 문서는 스트리밍 엔진이 여러 작업을 동시에 실행하기 때문에, 기존 인메모리 엔진을 기준으로 한 노드별 시간 측정이 오해를 일으킬 수 있다고 설명한다. 이 메서드를 호출하는 기존 코드는 수정이 필요하다.
Upgrade Checks
업그레이드에서 우선 확인할 지점은 결과 순서, 디스크 처리의 지원 범위, 제거된 API다. 순서에 의존하는 작업은 명시적 정렬이나 지원되는 순서 유지 옵션을 검토하고, profile()을 사용하는 부분은 별도로 찾아야 한다. Map 자료형을 읽는 코드도 함께 확인할 대상이다.
대용량 작업에서는 사용 중인 연산이 out-of-core 지원 대상에 포함되는지가 중요하다. 정렬에 적용되는 디스크 처리를 조인이나 그룹 집계에도 그대로 기대하기는 어렵다. 약 80%의 RAM 사용량에서 디스크로 넘기기 시작한다는 기준과 64GB의 기본 디스크 예산을 함께 고려해 실제 작업 조건을 점검할 필요가 있다.
향후 확인할 항목은 개발팀이 예고한 join과 group_by의 out-of-core 지원이다. 현재 공개된 지원 범위를 기준으로 이행하고, 후속 기능은 실제 지원 여부를 확인한 뒤 적용하는 접근이 적절하다.