TimescaleDB : Postgres optimisé time-series — déploiement 2026

📍 Article principal du cluster : Bases de données modernes 2026 : DuckDB, ClickHouse, TimescaleDB, pgvector
Cet article fait partie du cluster « Bases de données spécialisées ». Pour la vue d’ensemble complète, commencez par lire le pilier.

Introduction

Les données horodatées représentent aujourd’hui l’une des formes les plus courantes d’information dans les systèmes modernes : relevés de capteurs industriels, métriques serveur, transactions financières, journaux applicatifs, suivi énergétique. PostgreSQL, aussi puissant soit-il en tant que base relationnelle généraliste, n’est pas optimisé pour ce type de charge : les insertions massives en flux continu ralentissent à mesure que la table grossit, et les requêtes analytiques sur des fenêtres temporelles — « moyenne horaire des 30 derniers jours », « dernière valeur par capteur » — deviennent coûteuses sans une indexation spécialisée. TimescaleDB résout exactement ce problème.

TimescaleDB est une extension open-source pour PostgreSQL, développée par Timescale Inc., qui transforme Postgres en moteur de séries temporelles haute performance. Elle s’installe en deux commandes SQL, reste 100 % compatible avec l’écosystème Postgres existant (ORMs, outils d’administration, extensions comme PostGIS), et apporte trois innovations fondamentales : les hypertables avec partitionnement automatique en chunks temporels, les continuous aggregates pour pré-calculer les agrégations coûteuses, et la compression par colonnes qui peut réduire l’empreinte disque de 90 à 97 % sur les données historiques. Des benchmarks publiés sur timescale.com mesurent jusqu’à 8× plus d’insertions par seconde et des requêtes analytiques sur données compressées 2 à 10 fois plus rapides qu’en Postgres standard, selon le type de requête et le volume de données. Ce tutoriel vous guide de l’installation Docker jusqu’à l’intégration Grafana en sept étapes pratiques.

Prérequis

• Docker Engine 24+ et Docker Compose v2 installés (docs.docker.com/engine/install)
• Postgres 14 ou supérieur — TimescaleDB 2.x supporte Postgres 14, 15 et 16 ; nous utiliserons l’image Docker officielle timescale/timescaledb qui embarque les deux
• Ports libres : 5432 (TimescaleDB), 3000 (Grafana)
• Niveau : intermédiaire — vous savez écrire du SQL basique et lire un fichier YAML Docker Compose
• Temps estimé : environ 30 minutes pour les étapes 1 à 7

Étape 1 — Hypertables et chunks automatiques

Avant d’écrire la moindre commande, il est essentiel de comprendre le concept fondateur de TimescaleDB : la hypertable. En PostgreSQL classique, une table est un fichier unique qui grossit indéfiniment au fil des insertions. Pour une table de métriques qui reçoit des millions de lignes par jour, cela crée deux problèmes : les index deviennent trop volumineux pour tenir en mémoire RAM (ce qui ralentit les insertions), et les requêtes analytiques sur de grandes fenêtres temporelles doivent scanner l’intégralité de la table sans pouvoir exclure les partitions non pertinentes.

Une hypertable TimescaleDB est une table PostgreSQL ordinaire du point de vue de l’utilisateur, mais elle est transparentement partitionnée en chunks — des sous-tables internes — selon la dimension temporelle que vous choisissez (typiquement la colonne timestamp). Chaque chunk couvre une plage de temps définie (par exemple 7 jours par défaut, configurable), et TimescaleDB maintient automatiquement l’index de chaque chunk séparément. Résultat : les insertions récentes n’écrivent que dans le chunk courant, dont l’index tient facilement en RAM ; les requêtes sur une fenêtre de 30 jours scannent uniquement les 4 à 5 chunks concernés, ignorant les années de données historiques. Cette architecture de partitionnement automatique est entièrement transparente pour vos applications : elles continuent d’utiliser exactement le même SQL que pour une table Postgres standard.

La taille des chunks est configurable via le paramètre chunk_time_interval lors de la création de la hypertable. Pour des données IoT à haute fréquence (une mesure par seconde par capteur), 7 jours par chunk est un bon point de départ. Pour des données de facturation mensuelle moins fréquentes, vous pourrez utiliser des chunks de 30 jours. TimescaleDB ajuste lui-même les statistiques au fil du temps si vous utilisez l’option d’auto-sizing.

Étape 2 — Installer TimescaleDB via Docker

L’image Docker officielle timescale/timescaledb est publiée sur Docker Hub et embarque à la fois PostgreSQL et l’extension TimescaleDB préinstallée et précompilée. Il n’y a pas besoin de compiler quoi que ce soit manuellement : vous utilisez cette image à la place de l’image postgres officielle, et TimescaleDB est immédiatement disponible via une simple commande SQL. C’est le moyen le plus rapide et le plus reproductible de déployer TimescaleDB, idéal pour un environnement de développement local ou un serveur de production unique.

Créez un répertoire de travail, par exemple ~/timescaledb-iot, et placez-y le fichier Compose suivant :

# docker-compose.yml
services:
  timescaledb:
    image: timescale/timescaledb:2.14.2-pg16
    container_name: timescaledb
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: iot_metrics
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: changeme_secret
    volumes:
      - tsdb_data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  tsdb_data:

Le tag 2.14.2-pg16 désigne TimescaleDB version 2.14.2 sur PostgreSQL 16 — la combinaison recommandée pour 2026 selon docs.timescale.com/self-hosted/latest/install/installation-docker. Démarrez le service avec docker compose up -d, patientez quelques secondes le temps que Postgres initialise son répertoire de données, puis connectez-vous et activez l’extension :

# Se connecter au conteneur
docker exec -it timescaledb psql -U admin -d iot_metrics

-- Dans le shell psql, activer TimescaleDB
CREATE EXTENSION IF NOT EXISTS timescaledb;

Si la commande réussit, Postgres affiche un encart de bienvenue TimescaleDB et la mention CREATE EXTENSION. Vous pouvez vérifier que l’extension est bien active avec \dx qui doit lister timescaledb parmi les extensions installées. À partir de cet instant, toutes les fonctions TimescaleDB sont disponibles dans cette base de données.

Étape 3 — Créer une hypertable (capteurs IoT)

Maintenant que l’extension est activée, nous allons créer la structure de données pour un cas d’usage IoT concret : une flotte de capteurs environnementaux qui remontent température, humidité et qualité de l’air toutes les minutes. La table suit un schéma classique pour les séries temporelles — une colonne time de type TIMESTAMPTZ (timestamp avec fuseau horaire), un identifiant de capteur, et les valeurs mesurées. La conversion en hypertable se fait en une seule commande après la création de la table ordinaire.

-- Créer la table ordinaire d'abord
CREATE TABLE capteur_mesures (
    time        TIMESTAMPTZ   NOT NULL,
    capteur_id  TEXT          NOT NULL,
    temperature DOUBLE PRECISION,
    humidite    DOUBLE PRECISION,
    co2_ppm     INTEGER
);

-- Convertir en hypertable partitionnée par tranches de 7 jours
SELECT create_hypertable(
    'capteur_mesures',
    'time',
    chunk_time_interval => INTERVAL '7 days'
);

-- Index sur capteur_id pour les requêtes filtrées par capteur
CREATE INDEX ON capteur_mesures (capteur_id, time DESC);

La fonction create_hypertable transforme la table existante en hypertable sans déplacer les données (la table est vide à ce stade). Le partitionnement en tranches de 7 jours signifie que TimescaleDB créera automatiquement un nouveau chunk chaque semaine. Vous pouvez maintenant insérer des données exactement comme dans une table Postgres classique :

-- Insertion de données de test
INSERT INTO capteur_mesures (time, capteur_id, temperature, humidite, co2_ppm)
VALUES
    (NOW(),                    'CAPTEUR-DAKAR-01',  28.5, 72.3, 450),
    (NOW() - INTERVAL '1 min', 'CAPTEUR-DAKAR-01',  28.3, 72.8, 448),
    (NOW() - INTERVAL '2 min', 'CAPTEUR-DAKAR-01',  28.1, 73.0, 445),
    (NOW(),                    'CAPTEUR-ABIDJAN-01', 31.2, 80.1, 510),
    (NOW() - INTERVAL '1 min', 'CAPTEUR-ABIDJAN-01', 31.0, 80.5, 507);

-- Requête typique : dernière heure par capteur
SELECT capteur_id,
       time_bucket('5 minutes', time) AS bucket,
       AVG(temperature)               AS temp_moy,
       MAX(co2_ppm)                   AS co2_max
FROM   capteur_mesures
WHERE  time > NOW() - INTERVAL '1 hour'
GROUP  BY capteur_id, bucket
ORDER  BY capteur_id, bucket DESC;

La fonction time_bucket est l’une des fonctions phares de TimescaleDB : elle regroupe les timestamps en tranches régulières (ici 5 minutes) de façon nettement plus efficace que date_trunc en Postgres standard, car elle exploite directement la structure de partitionnement des chunks pour élaguer les blocs non pertinents avant même le scan.

Étape 4 — Continuous aggregates pour le pré-calcul

Calculer la moyenne horaire ou journalière d’un million de lignes à la volée à chaque requête est coûteux, surtout quand les dashboards Grafana actualisent leurs graphiques toutes les 30 secondes avec plusieurs panneaux simultanés. Les continuous aggregates (agrégats continus) de TimescaleDB résolvent ce problème en matérialisant automatiquement et de façon incrémentale les résultats d’une requête d’agrégation. Contrairement à une vue matérialisée Postgres standard qui nécessite un REFRESH manuel complet, un continuous aggregate ne recalcule que les nouveaux intervalles temporels depuis la dernière actualisation.

-- Créer un continuous aggregate : moyennes horaires par capteur
CREATE MATERIALIZED VIEW capteur_horaire
WITH (timescaledb.continuous) AS
SELECT
    time_bucket('1 hour', time) AS heure,
    capteur_id,
    AVG(temperature)            AS temp_moy,
    MIN(temperature)            AS temp_min,
    MAX(temperature)            AS temp_max,
    AVG(humidite)               AS humidite_moy,
    AVG(co2_ppm)                AS co2_moy,
    COUNT(*)                    AS nb_mesures
FROM capteur_mesures
GROUP BY heure, capteur_id
WITH NO DATA; -- Ne pas calculer les données historiques maintenant

-- Activer le rafraîchissement automatique
SELECT add_continuous_aggregate_policy(
    'capteur_horaire',
    start_offset => INTERVAL '3 hours',
    end_offset   => INTERVAL '1 hour',
    schedule_interval => INTERVAL '1 hour'
);

La politique de rafraîchissement configurée ici indique à TimescaleDB de recalculer les données entre il y a 3 heures et il y a 1 heure, toutes les heures. L’heure la plus récente (moins de 60 minutes) est exclue car les données peuvent encore arriver en retard — c’est la fenêtre end_offset. Pour interroger le continuous aggregate plutôt que la table brute, il suffit de changer le nom de la vue dans votre requête : SELECT * FROM capteur_horaire WHERE heure > NOW() - INTERVAL '7 days'. Les temps de réponse passent typiquement de plusieurs centaines de millisecondes (scan de la table brute) à quelques millisecondes (lecture de la vue matérialisée).

Étape 5 — Compression automatique des colonnes anciennes

Les données de séries temporelles ont une caractéristique précieuse pour la compression : les valeurs successives d’une même colonne sont souvent très proches ou identiques (la température varie peu d’une mesure à l’autre). TimescaleDB exploite cette propriété avec un format de stockage en colonnes pour les chunks anciens, combiné à des algorithmes de compression spécialisés (delta-delta pour les timestamps, Simple-8b pour les entiers, Gorilla pour les flottants — les mêmes algorithmes utilisés par Meta et Apple pour leurs systèmes de métriques). Dans la pratique, la compression atteint 90 à 97 % de réduction de l’empreinte disque sur des données IoT typiques, selon la variance des valeurs mesurées.

-- Activer la compression sur la table, ordonner par capteur
-- pour maximiser les répétitions dans chaque segment compressé
ALTER TABLE capteur_mesures
SET (timescaledb.compress,
     timescaledb.compress_segmentby = 'capteur_id',
     timescaledb.compress_orderby   = 'time DESC');

-- Politique : compresser les chunks de plus de 7 jours
SELECT add_compression_policy(
    'capteur_mesures',
    INTERVAL '7 days'
);

Le paramètre compress_segmentby = 'capteur_id' est crucial : il indique à TimescaleDB de regrouper les lignes d’un même capteur au sein d’un segment compressé, maximisant ainsi les séquences de valeurs similaires et donc le taux de compression. Sans ce paramètre, les lignes de différents capteurs seraient mélangées et la compression serait moins efficace. Une fois la politique activée, TimescaleDB compresse automatiquement les chunks anciens selon un job de background planifié. Vous pouvez vérifier l’état de compression avec la vue système chunk_compression_stats :

SELECT chunk_name,
       before_compression_total_bytes,
       after_compression_total_bytes,
       ROUND(100.0 * (1 - after_compression_total_bytes::numeric
             / NULLIF(before_compression_total_bytes, 0)), 1) AS taux_compression_pct
FROM   chunk_compression_stats('capteur_mesures')
ORDER  BY chunk_name;

Il n’est pas possible d’insérer ou de mettre à jour directement dans un chunk compressé : TimescaleDB crée automatiquement un chunk non compressé adjacent pour absorber les nouvelles insertions et les fusionne périodiquement. Ce comportement est transparent pour vos applications.

Étape 6 — Retention policy : auto-suppression des données anciennes

Conserver indéfiniment l’intégralité des mesures brutes n’est souvent pas nécessaire ni souhaitable : au-delà d’une certaine ancienneté, les données à la minute n’ont plus de valeur opérationnelle et il suffit de garder les agrégats horaires ou journaliers. TimescaleDB permet de définir une politique de rétention qui supprime automatiquement les chunks plus anciens qu’un horizon défini — une opération extrêmement rapide car elle ne requiert aucun DELETE ligne par ligne, mais simplement la suppression du fichier de chunk compressé correspondant.

-- Supprimer automatiquement les données brutes de plus de 90 jours
SELECT add_retention_policy(
    'capteur_mesures',
    INTERVAL '90 days'
);

-- Vérifier les politiques actives
SELECT * FROM timescaledb_information.jobs
WHERE  proc_name IN ('policy_retention', 'policy_compression',
                     'policy_refresh_continuous_aggregate');

Avec cette configuration, TimescaleDB maintient 90 jours de données brutes (environ toutes les minutes), compresse les chunks de plus de 7 jours, et les données plus anciennes que 90 jours sont automatiquement supprimées. Les continuous aggregates (vue capteur_horaire) peuvent quant à eux conserver une rétention plus longue — il suffit de ne pas définir de politique de rétention sur la vue matérialisée, ou de la définir avec un horizon plus lointain (un an, cinq ans). Cette architecture — données brutes pour 90 jours, agrégats horaires pour un an ou plus — est le schéma recommandé par l’équipe Timescale pour les déploiements IoT à grande échelle.

Étape 7 — Intégration Grafana datasource

Grafana se connecte à TimescaleDB via le plugin PostgreSQL natif, sans aucune installation supplémentaire. TimescaleDB étant une extension Postgres standard, Grafana l’interroge exactement comme il interrogerait une base Postgres, mais vous pouvez utiliser les fonctions TimescaleDB (notamment time_bucket) directement dans vos requêtes de panel. C’est l’une des forces de l’approche extension de TimescaleDB : vous bénéficiez de tout l’écosystème Grafana existant sans configuration spéciale.

Ajoutez Grafana à votre fichier Compose :

# Ajouter au docker-compose.yml existant
  grafana:
    image: grafana/grafana:10.4.2
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme
    volumes:
      - grafana_data:/var/lib/grafana
    restart: unless-stopped
    depends_on:
      - timescaledb

volumes:
  tsdb_data:
  grafana_data:

Dans l’interface Grafana (http://localhost:3000), allez dans Connections → Data sources → Add data source et choisissez PostgreSQL. Remplissez les champs : Host = timescaledb:5432, Database = iot_metrics, User = admin, Password = changeme_secret, TLS = disabled (pour un usage local). Cliquez sur Save & Test — Grafana doit afficher « Database Connection OK ». Vous pouvez ensuite créer un panel de type Time Series avec la requête suivante, qui utilise la variable Grafana $__timeFilter pour adapter automatiquement la plage temporelle au zoom du dashboard :

SELECT
    heure                            AS time,
    capteur_id                       AS metric,
    temp_moy
FROM capteur_horaire
WHERE $__timeFilter(heure)
  AND capteur_id LIKE 'CAPTEUR-DAKAR%'
ORDER BY heure;

Grafana interprète automatiquement la colonne time comme l’axe temporel et metric comme le nom de la série. Chaque valeur distincte de capteur_id sera affichée comme une courbe séparée dans le panel. Pour de meilleures performances sur les grands intervalles, pointez Grafana vers la vue capteur_horaire (continuous aggregate) plutôt que vers la table brute capteur_mesures : les requêtes seront 10 à 100 fois plus rapides selon la fenêtre temporelle.

Erreurs fréquentes

Adaptation au contexte ouest-africain

TimescaleDB est particulièrement bien adapté aux projets de terrain qui se développent en Afrique de l’Ouest, où plusieurs cas d’usage émergent avec force : le monitoring agritech via capteurs LoRa, le suivi de la consommation électrique des installations solaires, et la surveillance de la qualité de l’eau dans les zones rurales et périurbaines.

Dans le domaine de l’agriculture connectée, des réseaux LoRaWAN déployés sur des périmètres maraîchers au Sénégal, au Mali ou au Burkina Faso collectent des relevés de température du sol, d’humidité et d’ensoleillement toutes les 15 minutes via des passerelles LoRa raccordées à internet par 4G. Ces capteurs génèrent des flux de données modestes en volume mais continus — typiquement 50 à 200 capteurs sur un périmètre, soit 5 000 à 20 000 lignes par heure. Une instance TimescaleDB sur un VPS d’entrée de gamme (Hetzner CX22, 4 Go de RAM, 40 Go NVMe à 5 euros par mois) gère ce volume sans difficulté avec une rétention brute de 90 jours et des agrégats journaliers sur un an. La compression à 95 % signifie qu’un an de données brutes d’un réseau de 200 capteurs mesurant 5 valeurs toutes les 15 minutes tient dans moins de 2 gigaoctets — une empreinte négligeable.

Pour le suivi de la consommation électrique des installations photovoltaïques, les onduleurs solaires modernes (notamment ceux des marques Huawei, Growatt et Sungrow populaires en Afrique de l’Ouest) exposent leurs métriques via Modbus TCP ou des API REST propriétaires. Des scripts Python ou des agents comme Telegraf collectent ces données toutes les minutes (puissance produite, tension, courant, température du panneau, état des batteries) et les poussent vers TimescaleDB. Les continuous aggregates permettent ensuite de calculer automatiquement la production horaire et journalière pour le tableau de bord de l’installateur, sans écrire une seule requête d’agrégation à la volée.

La surveillance de la qualité de l’eau est un autre cas d’usage à fort impact social. Des capteurs mesurant pH, turbidité, conductivité et chlore résiduel, déployés sur des points de pompage ou des châteaux d’eau, remontent leurs valeurs toutes les 5 minutes. La retention policy de TimescaleDB peut être configurée pour conserver un an de données brutes (conformément aux exigences réglementaires sanitaires de la plupart des pays de la CEDEAO), puis archiver les agrégats horaires sur cinq ans, le tout dans moins de 10 gigaoctets de stockage. La compression à 95 % n’est pas une promesse marketing sur ce type de données : des capteurs qui mesurent un pH stable autour de 7,2 avec de légères variations journalières produisent des séquences de valeurs très compressibles, et des taux de réduction de 95 à 97 % sont régulièrement constatés en production.

Sur la question de la connectivité, TimescaleDB s’intègre naturellement dans des architectures edge-cloud : un Raspberry Pi ou un mini-PC industriel sur site peut faire tourner une instance TimescaleDB locale pour absorber les données en cas de coupure internet (fréquente dans certaines zones), puis synchroniser avec l’instance cloud principale à la reconnexion via des scripts de réplication basés sur la logical replication PostgreSQL.

Tutoriels frères

• DuckDB : analyse de CSV et Parquet depuis Python — tutoriel 2026 — moteur analytique embarqué pour traiter les exports TimescaleDB hors ligne
• ClickHouse : ingestion et analyse de logs à grande échelle — tutoriel 2026 — alternative pour les volumes de plusieurs milliards de lignes
• pgvector : recherche sémantique dans PostgreSQL — tutoriel 2026 — autre extension Postgres pour enrichir votre infrastructure de données

Pour aller plus loin

• 🔝 Retour au pilier : Bases de données modernes 2026 : DuckDB, ClickHouse, TimescaleDB, pgvector
• Documentation officielle TimescaleDB — auto-hébergement — référence complète des fonctions SQL, politiques, compression et réplication
• GitHub timescale/timescaledb — code source, issues, releases et notes de migration entre versions majeures
• Prochain tutoriel recommandé du cluster : pgvector pour la recherche vectorielle dans PostgreSQL

FAQ

Q : TimescaleDB est-il 100 % compatible avec les extensions PostgreSQL existantes comme PostGIS ou pgvector ?
R : Oui. TimescaleDB est une extension parmi d’autres dans l’écosystème PostgreSQL et coexiste sans conflit avec PostGIS, pgvector, pg_partman, et la grande majorité des extensions populaires. Vous pouvez créer des hypertables sur des tables qui ont des colonnes de type géographique PostGIS, ce qui permet par exemple de stocker des positions GPS horodatées de véhicules ou de drones avec toutes les fonctions d’analyse spatiotemporelle. La compatibilité est documentée sur docs.timescale.com.

Q : Puis-je utiliser TimescaleDB avec mon ORM existant (SQLAlchemy, Sequelize, ActiveRecord) ?
R : Oui, sans modification. Du point de vue de l’ORM, une hypertable TimescaleDB est une table PostgreSQL ordinaire. Les ORM peuvent en créer, y insérer, la lire et la mettre à jour avec exactement le même code qu’ils utiliseraient pour une table Postgres standard. La seule limitation concerne les migrations automatiques : certains ORMs qui gèrent le schéma automatiquement peuvent ne pas connaître la fonction create_hypertable — vous devrez alors ajouter une migration SQL manuelle pour appeler cette fonction après la création de la table.

Q : Quelle est la différence entre TimescaleDB et InfluxDB, l’autre base de données time-series populaire ?
R : La différence fondamentale est que TimescaleDB est une extension PostgreSQL — vous restez dans l’écosystème SQL relationnel standard, avec tous ses avantages (jointures, transactions ACID, contraintes, triggers, procédures stockées, extensions tierces). InfluxDB est une base de données dédiée avec son propre langage de requête (InfluxQL puis Flux), ses propres outils d’administration, et une compatibilité limitée avec l’écosystème SQL. Pour une PME qui a déjà des compétences PostgreSQL en interne, TimescaleDB est souvent le choix plus rationnel car il minimise la courbe d’apprentissage et la dette opérationnelle.

Q : Comment fonctionnent les backups d’une base TimescaleDB ?
R : Exactement comme un backup PostgreSQL classique. pg_dump et pg_basebackup fonctionnent sans modification particulière. Pour les backups logiques avec pg_dump, les données sont exportées telles quelles, y compris les données compressées (qui seront décompressées lors de l’export). Pour les backups physiques avec pg_basebackup, toute la structure de chunks est préservée. Des outils comme pgBackRest sont recommandés pour les déploiements production car ils supportent les backups incrémentiels et la compression à la volée.

Q : TimescaleDB fonctionne-t-il en mode haute disponibilité avec Patroni ou Repmgr ?
R : Oui. TimescaleDB est entièrement compatible avec les solutions de haute disponibilité PostgreSQL standard comme Patroni, Repmgr et pgpool-II. La réplication de streaming Postgres fonctionne normalement et réplique les hypertables, les chunks compressés et toutes les métadonnées TimescaleDB. Timescale Inc. propose également une offre cloud managée (Timescale Cloud) avec HA intégrée, mais pour l’auto-hébergement, Patroni reste la solution la plus robuste et la mieux documentée.

Q : Peut-on décompresser un chunk pour y faire des modifications puis le recompresser ?
R : Oui. La commande SELECT decompress_chunk(chunk_id) décompresse un chunk spécifique et le rend éditable. Après vos modifications (UPDATE, DELETE, INSERT), vous pouvez le recompresser manuellement avec SELECT compress_chunk(chunk_id), ou simplement attendre que la politique de compression automatique le prenne en charge. Cette opération est transparente et n’affecte pas les autres chunks ni les requêtes en cours sur la hypertable.

Site réalisé par [ITS] ITSkillsCenter