InfluxDB 3 : faut-il l’adopter pour vos données time-series ?

Temps de lecture estimé : 9 min

En résumé

InfluxDB est une base de données spécialisée dans les séries temporelles : elle ingère et requête des volumes massifs de données horodatées (capteurs IoT, métriques d’infrastructure, finance, météo) en s’appuyant sur la compression, le partitionnement temporel et l’append-only.

Par rapport à InfluxDB 2, la v3 change profondément d’architecture : elle abandonne le moteur TSM au profit d’un stockage colonnaire basé sur Apache Parquet, s’appuie sur l’écosystème Apache Arrow / DataFusion et supporte SQL nativement. Son principal apport pour les projets IoT et industriels est la gestion beaucoup plus souple de la cardinalité des tags, historiquement sensible dans InfluxDB v2.

Mais InfluxDB 3 n’est pas un choix automatique. Si votre projet dépend fortement de l’interface native, des dashboards intégrés ou d’une gestion fine des droits directement dans l’UI, la v2 peut rester plus confortable à court terme. La bonne décision dépend donc de votre workload, de votre modèle de données, de votre stratégie de rétention et de votre niveau d’exigence en exploitation.

 

Qu’est-ce qu’une base de données time-series ?

Une base de données time-series (TSDB) est une base optimisée pour un type très particulier de donnée : la mesure horodatée. Chaque enregistrement comporte un timestamp, une ou plusieurs valeurs, et éventuellement des métadonnées de contexte. L’index primaire est toujours le temps.

Exemples typiques :

• température d’un capteur industriel toutes les secondes 
• consommation CPU d’un serveur toutes les 10 secondes 
• prix d’un actif financier à chaque transaction 
• latence d’une API mesurée en continu 
• vibration d’une machine sur une chaîne de production.

Trois propriétés distinguent une TSDB d’une base relationnelle :

• Append-only : on n’écrase pas une mesure, on en ajoute une nouvelle à t+1. Un capteur à 14h00:01 ne « met pas à jour » sa valeur de 14h00:00 ; il en écrit une autre.
• Compression et partitionnement temporel natifs : les données sont stockées par blocs (shards) sur des plages de temps, ce qui rend les requêtes par fenêtre extrêmement rapides.
• Agrégation à la lecture : downsampling, moyennes pondérées, windowing, max/min sur intervalle… sont des opérations de premier niveau, pas des bricolages SQL.

Conséquence : Si vos requêtes portent principalement sur des plages de temps (par exemple, vous tracez 300 000 capteurs sur 12 mois), une TSDB est pertinente. Si la dimension temporelle est secondaire dans votre cas d’usage, PostgreSQL, un moteur analytique ou une base relationnelle classique peuvent être plus adaptés.

 

Quand utiliser InfluxDB : 4 cas d’usage typiques

• Monitoring d’infrastructure : métriques CPU, RAM, latence applicative, logs structurés.
• IoT industriel : capteurs de pression, de température, d’humidité, vibrations machines. C’est le cas d’usage où InfluxDB excelle. Nous l’avons mis en production chez un grand énergéticien français qui exploite ≈ 300 000 capteurs hiérarchisés zone → barrage → capteur. Ce type d’architecture met en lumière les sujets critiques : cardinalité, modèle tags/fields, stratégie de rétention, downsampling et coût de requêtage.
• Données financières et marché : ticks, ordres, cotation set événements de marché sont des données naturellement time-series. InfluxDB peut être pertinent pour des cas d’analyse temporelle, de visualisation ou de monitoring d’indicateurs.
• Dashboarding temps réel : couplé à Grafana, InfluxDB sert directement des graphes auto-agrégés au nombre de pixels disponibles. Pas besoin de descendre 1 million de points pour en afficher 800.

 

Comment InfluxDB stocke les données : le modèle Line Protocol

InfluxDB ingère les données via son Line Protocol HTTP. Quatre concepts à connaître :

• Measurement : l’équivalent d’une table. On en crée un par type de mesure : temperature, cpu, humidity.
• Tags : des métadonnées de type chaîne, indexées, faites pour le pré-filtrage (zone=normandie, site=barrage_3). En v2, mettre un identifiant à forte cardinalité dans un tag dégrade les performances. En v3, ce n’est plus le cas.
• Fields : les valeurs mesurées, typées (float, int, bool, string). Le schéma est figé par type : on ne mélange pas float et string dans le même field.
• Timestamp : l’index, toujours présent, généralement en nanosecondes.

 

  

 

Sous le capot, InfluxDB n’écrit pas chaque mesure sur disque immédiatement. Il les accumule dans un Write-Ahead Log (WAL) en mémoire, les flush dans un cache, puis les compacte vers le stockage durable. C’est ce design qui permet l’ingestion massive : la latence d’I/O par mesure est amortie sur un batch.

 

 

InfluxDB 2 vs InfluxDB 3 : ce qui change vraiment

Sur la performance : la version 3 a été annoncée par InfluxData comme « jusqu’à 100× plus rapide » à la lecture. Ce chiffre provient de la communication de l’éditeur et n’est pas, à ce jour, confirmé par les benchmarks indépendants publiés : sur la version Core, certains tests tiers mesurent même des requêtes plus lentes que sur les versions antérieures. La promesse de performance doit toutefois être validée sur votre propre workload. Le gain réellement structurant et vérifié de la v3 est ailleurs : la disparition de la dégradation liée à la cardinalité et l’alignement sur l’écosystème Apache Arrow / DataFusion.

Le saut technique de la v3 est réel : passer à un format colonnaire Parquet aligne InfluxDB sur l’écosystème data moderne (Arrow, DataFusion, lakehouse). Mais en mai 2026, la v3 reste en rattrapage fonctionnel face à la v2 : si votre projet dépend de l’UI native, des dashboards intégrés ou de la gestion fine des droits, restez sur la v2 pour l’instant et planifiez la migration. Le détail des fonctionnalités version par version est suivi dans la documentation officielle InfluxData v3.

 

 

Faut-il choisir InfluxDB 2 ou InfluxDB 3 en 2026 ?

Pour un nouveau projet time-series, InfluxDB 3 est le choix à privilégier si :

• vous avez une forte volumétrie de données horodatées 
• vous devez gérer beaucoup d’entités : capteurs, équipements, devices, sites 
• vous souhaitez requêter en SQL
• vous acceptez d’utiliser Grafana pour la visualisation avancée
• vous voulez vous aligner sur des formats ouverts comme Parquet.

InfluxDB 2 reste pertinent si :

• votre projet dépend fortement de l’UI native
• vos équipes utilisent déjà Flux
• vous avez des dashboards existants dans InfluxDB v2
• votre modèle de droits et d’exploitation est déjà stabilisé
• le coût de migration dépasse le bénéfice attendu à court terme.
• vous avez une gestion fine des droits pour les tokens et les utlisateurs

En pratique, la bonne approche consiste souvent à tester InfluxDB 3 sur un périmètre représentatif : un flux réel, un modèle tags/fields proche de la production, une volumétrie crédible et des requêtes métier réalistes.

 

Politique de rétention et shards : penser au coût avant la mise en prod

InfluxDB gère nativement l’expiration des données via les retention policies, définies au niveau d’un bucket (ou d’une base). Vous lui dites : « ces données ne m’intéressent plus au-delà de 6 mois », il les supprime tout seul.

Sous le capot, il découpe les données en shards (partitions temporelles) dont la granularité dépend de la durée de rétention :

• Rétention ≤ 2 jours → shards de 1 heure
• Rétention ≤ 6 mois → shards de 1 jour
• Rétention > 6 mois ou infinie → shards de 7 jours, voire plus

Logique sous-jacente : plus la fenêtre est large, plus on accepte de regrouper pour amortir la compression. L’analogie cloud est juste : les vieilles données restent disponibles, simplement un peu plus lentes à exhumer, un peu comme un stockage glacier.

Retour d’expérience : déployer InfluxDB sur 300 000 capteurs

Chez un grand énergéticien français, nous avons modélisé une flotte de ≈ 300 000 capteurs hiérarchisés selon une arborescence zone → site → barrage → capteur. Trois leçons :

• Ne pas indexer par capteur. Avec des centaines de milliers d’entités, la question n’est pas seulement “InfluxDB peut-il stocker ces données ?”. La vraie question est : “Comment les métiers vont-ils les requêter ?” Dans notre cas, la maille utile était rarement “un capteur isolé sur 12 mois”. Elle était plutôt : “tous les capteurs d’un barrage sur une plage temporelle”. Le modèle doit donc partir des requêtes métier, pas seulement de la structure technique des équipements.

• Penser le modèle tags/fields en amont. Les tags servent à filtrer (zone, site, type de capteur, fabricant). Les fields portent les valeurs et leurs métadonnées d’horodatage interne. Migrer un tag en field après coup est faisable mais coûteux. Il vaut mieux investir quelques ateliers de conception avant la mise en production que corriger le modèle une fois que la base contient déjà des milliards de points.

• Profiter du downsampling automatique. Le métier a demandé un agrégat toutes les 5 minutes ? InfluxDB fait la moyenne pondérée sur la durée nativement, pas besoin de recoder une couche d’agrégation comme nous l’avions fait dans une version antérieure sans TSDB.

La stack standard : Telegraf + InfluxDB + Grafana

InfluxData a misé sur l’interopérabilité plutôt que sur un produit fermé. La stack la plus courante :

• Telegraf en collecte (équivalent open-source de Prometheus côté agent), avec plus de 200 plugins d’entrée.
• InfluxDB en stockage et moteur de requête.
• Grafana en visualisation, branché en data source InfluxDB.

Cette stack reste valable en v3, même si l’UI InfluxDB s’est appauvrie : c’est un choix assumé d’InfluxData de « faire ce qu’il fait bien et laisser Grafana faire le reste ».

C’est plus modulaire, plus lisible et souvent plus robuste en exploitation.

Quand NE PAS choisir InfluxDB

InfluxDB n’est pas la réponse universelle à tous les problèmes de données horodatées.
Évitez InfluxDB si :

• Vos requêtes n’ont pas de dimension temporelle dominante → PostgreSQL ou un moteur relationnel reste meilleur.
• Vous avez besoin de mises à jour fréquentes sur des données déjà écrites → InfluxDB sait le faire, mais ce n’est pas son terrain naturel. Préférez TimescaleDB (extension PostgreSQL) qui gère mieux les updates. Le classement DB-Engines des bases time-series donne un bon panorama des alternatives et de leur dynamique.
• Vous travaillez dans un grand groupe qui a déjà racheté une brique time-series interne → vérifiez avant de prescrire.
• Vous avez besoin de jointures relationnelles complexes → InfluxDB en v3 progresse, mais ce n’est pas Snowflake.

Checklist avant d’adopter InfluxDB 3

Avant de lancer un projet InfluxDB 3, posez au minimum ces questions :

1. Quel est le volume de points ingérés par seconde ?
2. Quelle est la cardinalité réelle des tags ?
3. Quelles sont les requêtes métier les plus fréquentes ?
4. Quelle durée de conservation pour les données brutes ?
5. Quels agrégats doivent être conservés dans le temps ?
6. Grafana couvre-t-il les besoins de visualisation ?
7. Les équipes ont-elles besoin de SQL, Flux ou InfluxQL ?
8. La gestion des droits attendue est-elle compatible avec l’édition choisie ?
9. La migration depuis InfluxDB 2 est-elle nécessaire ou peut-on isoler un nouveau périmètre ?
10. Quels benchmarks doivent être réalisés avant la mise en production ?

Conclusion : InfluxDB 3 est prometteur, mais doit être benchmarké

InfluxDB 3 marque une vraie rupture technique. Son architecture colonnaire, son support SQL et sa meilleure gestion de la cardinalité en font une option solide pour les nouveaux projets time-series, en particulier dans l’IoT, le monitoring et les plateformes industrielles.

Mais le choix doit rester pragmatique. Si votre besoin repose sur une UI riche, des dashboards natifs ou une gouvernance fine déjà en place dans InfluxDB 2, la migration doit être planifiée plutôt que subie.

---

 

Pour aller plus loin

KAIZEN Solutions accompagne des plateformes data IoT en production sur InfluxDB v2 et v3 (voir notre expertise Data Engineering : https://kaizen-solutions.net/nos-expertises/nos-expertises-techniques/data-algorithmie/ ). Si vous évaluez une migration ou un nouveau projet capteurs / monitoring, nos équipes peuvent challenger votre modèle tags/fields, votre stratégie de rétention et votre choix de version.

 

 

---

 

A propos de l'auteur

Anaïs ALEX est Responsable du pôle Software chez Kaizen Solutions. Ingénieure diplômée de Grenoble INP - Phelma (spécialité Signal, Image, Communication, Multimédia), elle cumule près de 10 ans d'expérience en dék chez TiHive (imagerie THz), Software Developer chez Thales sur des systèmes industriels embarqués, et Responsable développement logiciel et IA chez Morphosense, où elle a piloté des projets de Machine Learning sur séries temporelles et images issues de capteurs. Côté stack, elle évolue principalement en .NET Core, Python, Azure et architectures micro-services.
Ce REX est issu d'un lunch Data & Software qu'elle a présenté en interne chez KAIZEN Solutions en 2025.