Analyse colonnaire sur vos propres données, depuis le Québec.

Trois étapes

Les ensembles de données regroupent vos tables — même forme qu'un dataset BigQuery ou un schéma. Chaque ensemble est un seul fichier DuckDB sur le disque, avec les fichiers sources bruts conservés à côté pour la traçabilité.

SELECT region,
       AVG(prix)     AS prix_moyen,
       COUNT(*)      AS commandes,
       SUM(quantite) AS unites
  FROM ventes
 GROUP BY region
 ORDER BY prix_moyen DESC;

Pourquoi c'est rapide

PostgreSQL stocke les données ligne par ligne. SELECT AVG(prix) FROM commandes lit toutes les colonnes de chaque ligne — même si vous n'avez demandé qu'une seule colonne. Atelier de données utilise DuckDB, qui stocke chaque colonne séparément. Les agrégations ne touchent que les colonnes référencées par la requête, souvent 2 à 5 % des octets sur disque.

En plus, DuckDB parallélise une requête unique sur chaque cœur disponible, traite les données en lots vectorisés et prend en charge le pushdown automatique des prédicats dans les métadonnées Parquet. Sur des tables de 10 millions de lignes, vous obtenez une ergonomie de type BigQuery sur une machine hébergée au Québec, sans frais à l'octet scanné.

Ce qu'on ne peut pas faire ici : scanner une table de 10 To sur 5 000 travailleurs. Pour ça, BigQuery reste le bon outil. Atelier de données est pour la longue traîne des tableaux de bord, de l'analyse ad hoc et des pipelines BI qui tiennent confortablement dans quelques dizaines de gigaoctets — les charges qui ne justifient pas un entrepôt mais qui dépassent Postgres + agrégation manuelle.

Sécuritaire à exposer aux requêtes utilisateurs

Les requêtes utilisateurs sont exécutées en lecture seule, l'accès au système de fichiers est désactivé — read_csv_auto('/etc/passwd') et autres appels hors base retournent une erreur claire. Chaque requête reçoit un plafond de mémoire borné par un cgroup, un délai limite et son propre sous-processus ; une agrégation hors de contrôle est tuée par OOM dans son propre scope, jamais sur la machine hôte.

Formats et SQL pris en charge

L'ingestion accepte .csv, .parquet, .json et .jsonl / .ndjson. Les types sont inférés par un balayage complet à l'ingestion, donc les colonnes parsent proprement même quand les 1 000 premières lignes se ressemblent. Les requêtes utilisent le SQL DuckDB — un sur-ensemble compatible avec Postgres incluant les fenêtres, CTE, opérateurs de chemin JSON complets et types tableaux. Le SQL ANSI standard fonctionne.

Forfaits

Inclus dans tous les forfaits Canner. Démarrage suffit pour des tests réels ; De base et Pro montent à des charges BI sérieuses.

Où vos données résident

Sur disque à Montréal, détenues par l'utilisateur de déploiement sur le même VPS qui exécute vos projets. Aucun plan de données tiers. Aucune télémétrie sur le contenu de vos requêtes — uniquement des décomptes agrégés (succès / échec / délai) pour la facturation. Le journal des requêtes vous montre quel SQL a été exécuté et quand ; les lignes de résultat elles-mêmes ne sont jamais conservées au-delà de la réponse.

Prochaines étapes

La phase 2 livre les requêtes planifiées (exécution nocturne, résultats en cache), l'export CSV/Parquet de toute requête, et la lecture fédérée de la base Postgres de votre projet (pas d'ETL — interrogez Postgres et les fichiers téléversés dans un même SELECT). La phase 3 ajoute une sous-commande CLI canner workshop pour rediriger les résultats vers un terminal.