Polars 2.0 introduit le traitement hors mémoire et des requêtes SQL plus rapides

L'équipe Polars a publié la version 2.0 de sa bibliothèque de traitement de données, marquant un changement significatif dans la gestion de la mémoire et des charges de travail SQL par le moteur. Publiée le 6 octobre 2026, cette mise à jour majeure introduit le traitement hors mémoire (out-of-core) comme fonctionnalité par défaut et positionne Polars parmi les meilleurs performeurs dans les benchmarks SQL standard face à des concurrents tels que DuckDB et DataFusion.

Ce qui s'est passé

Cette release se concentre sur la résilience et la performance plutôt que sur l'ajout de nouvelles fonctionnalités. Le changement le plus impactant est que l'appel de collect sur un LazyFrame utilise désormais le moteur de streaming par défaut. Ce basculement permet à Polars de gérer des jeux de données plus volumineux que la RAM disponible en déversant les données temporaires sur le disque. Le système commence ce processus de spill-to-disk lorsque l'utilisation de la mémoire atteint environ 80 % de la RAM disponible, avec un budget disque par défaut de 64 Go. Actuellement, des opérations telles que le tri, les fonctions de fenêtre et de nombreuses expressions prennent en charge ce comportement hors mémoire, tandis que les jointures et les opérations group-by sont prévues pour des mises à jour futures.

Le moteur de streaming ne garantissant pas l'ordre des lignes pour des opérations telles que join, group_by et unpivot, ce changement a nécessité une augmentation majeure de la version. Les utilisateurs dépendant d'un ordre spécifique des lignes doivent désormais définir explicitement maintain_order=True. Ce comportement par défaut vise à rendre Polars plus robuste pour les praticiens occasionnels des données travaillant sur des charges de travail à forte consommation mémoire, prévenant ainsi les plantages qui se produisaient auparavant lorsque les jeux de données dépassaient les limites physiques de la mémoire.

En plus de la gestion de la mémoire, Polars 2.0 traite le SQL comme un citoyen de première classe. La bibliothèque a considérablement augmenté sa couverture SQL et amélioré son optimiseur grâce à un meilleur réordonnancement des jointures, à l'élimination des sous-plans communs et aux prédicats dynamiques. Ces améliorations permettent à Polars d'exécuter des requêtes SQL complexes plus efficacement, comblant le fossé entre la manipulation programmatique des données et les interactions traditionnelles avec les bases de données.

Comment cela fonctionne

Les gains de performance dans l'exécution SQL proviennent d'optimisations profondes au sein du moteur de requêtes. Polars exploite désormais les filtres bloom et les prédicats dynamiques pour réduire la quantité de données traitées lors de l'exécution des requêtes. En éliminant les sous-plans communs et en réordonnant efficacement les jointures, le moteur minimise les calculs redondants. Ces améliorations techniques permettent à Polars de rivaliser directement avec les bases de données analytiques établies.

Pour valider ces affirmations, l'équipe a exécuté des benchmarks utilisant des données dérivées de TPC-H et TPC-DS sur des instances AWS c7a. Ils ont comparé Polars à DuckDB 1.5.6, DuckDB 2.0 alpha et DataFusion 54.0.0. Les tests consistaient à exécuter chaque requête cinq fois dans un contexte chaud, à vider le cache de fichiers entre les moteurs et à conserver le meilleur temps d'exécution. Les résultats ont montré que Polars était le moteur le plus rapide dans presque tous les benchmarks sur des machines de 16 vCPU et 192 vCPU, bien qu'il ait présenté une certaine surcharge sur les requêtes de petits volumes de données lorsqu'il était mis à l'échelle à 192 threads.

Détails clés

• Le traitement hors mémoire est activé par défaut, avec un débordement sur disque à ~80 % d'utilisation de la RAM et un budget disque par défaut de 64 Go.
• Le moteur de streaming est désormais la valeur par défaut pour collect, ce qui peut modifier l'ordre des lignes sauf si maintain_order=True est défini.
• Polars a devancé DuckDB et DataFusion dans les benchmarks TPC-H et TPC-DS1 sur les instances c7a.4xlarge et c7a.metal.
• Un nouveau dtype Map prend directement en charge le MapType d'Arrow, permettant des recherches et itérations de clés de type dictionnaire.
• Une vérification de type plus stricte et collect_schema() permettent des boucles de retour d'information plus rapides pour les agents IA et les développeurs.
• DataFusion a expiré ou manqué de mémoire sur plusieurs requêtes où Polars et DuckDB se sont terminés avec succès.

Pourquoi c'est important

Pour les ingénieurs logiciels et les data scientists, le support hors mémoire par défaut signifie une fiabilité accrue lors du traitement de grands jeux de données. Auparavant, dépasser les limites de mémoire faisait planter le processus, nécessitant un découpage manuel ou des outils externes. Désormais, Polars peut gérer gracieusement des charges de travail supérieures à la mémoire en utilisant l'espace disque, facilitant ainsi la construction de pipelines de données résilients sans ajustements d'infrastructure approfondis. Cela est particulièrement précieux pour les équipes qui ne disposent pas de ressources dédiées en ingénierie des données pour gérer des systèmes distribués complexes.

Le système de types plus strict et la validation de schéma répondent également à un besoin croissant dans le développement piloté par l'IA. À mesure que davantage de développeurs utilisent des agents IA pour générer du code, la détection précoce des erreurs devient critique. En échouant rapidement sur les incompatibilités de schéma via collect_schema(), Polars aide les agents et les humains à itérer plus vite. Cela réduit le temps passé à déboguer des échecs silencieux ou des types de données incorrects au cœur d'un pipeline, conduisant à un code de traitement de données plus maintenable et correct.

Ce que vous pouvez faire

• Passez à Polars 2.0 et consultez le guide de migration fourni par l'équipe pour gérer les changements cassants (breaking changes).
• Testez vos pipelines existants pour les dépendances à l'ordre des lignes et ajoutez maintain_order=True là où c'est nécessaire.
• Expérimentez avec le nouveau dtype Map pour gérer les structures de données imbriquées clé-valeur plus efficacement.
• Exécutez des requêtes SQL directement dans Polars pour tirer parti de l'optimiseur amélioré et comparer les performances avec votre stack actuelle.
• Utilisez collect_schema() dans votre workflow de développement pour détecter les erreurs de type avant d'exécuter des opérations lourdes sur les données.
• Surveillez l'utilisation de la mémoire et ajustez le seuil de débordement sur disque si votre charge de travail nécessite une allocation de ressources différente.