Presque toute application accumule un ensemble de tâches SQL qui doivent s'exécuter à heure fixe. Un cumul de revenus nocturne. Une synchronisation horaire qui aplatit quelques tables en une seule que votre tableau de bord lit à bon marché. Une requête de rapprochement qui vérifie le grand livre de la veille. Individuellement, c'est une douzaine de lignes de SQL. Ensemble, c'est la raison pour laquelle les équipes montent un orchestrateur.
Et l'orchestrateur est presque toujours plus lourd que le travail. Vous optez pour un Airflow géré, une tâche dbt Cloud ou une petite machine toujours allumée qui exécute cron — et voilà vos données extraites hors de votre base, vers un service distinct, pour y être traitées et réécrites. Pour une équipe canadienne soumise à une clause de résidence des données, ce service distinct est souvent exactement ce que vous cherchiez à éviter : un SaaS hébergé aux États-Unis avec une copie de vos lignes.
Depuis cette semaine, Canner le fait nativement. Écrivez du SQL, définissez une planification, et il s'exécute sur vos propres bases — à Montréal, sans rien extraire.
Du SQL plus une planification — c'est tout
Une requête planifiée, c'est exactement deux entrées : le SQL et une planification cron. Aucun pipeline à définir, aucune table de destination à pré-déclarer, aucune chaîne de connexion à coller. Vous écrivez l'instruction que vous exécuteriez à la main, et Canner l'exécute pour vous selon la planification choisie, en conservant un historique complet.
C'est le pendant SQL des tâches planifiées, qui envoient une requête HTTP POST à un webhook de votre application. Optez pour une tâche planifiée quand le travail vit dans votre code applicatif; optez pour une requête planifiée quand le travail est du SQL.
Référencez vos bases par leur nom
Une requête planifiée peut atteindre n'importe quelle base de projet que votre compte possède. Vous la nommez dans le SQL — projet.schema.table. C'est toute l'étape de « connexion » (un trait d'union dans un slug devient un tiret bas : ma-boutique → ma_boutique). Et comme vous pouvez en nommer plusieurs, une seule instruction peut faire le pont entre projets que vous possédez :
-- Cumuler les commandes de la veille dans une table de rapport,
-- écrite directement dans le Postgres du projet.
CREATE OR REPLACE TABLE boutique.public.ventes_jour AS
SELECT date_trunc('day', created_at) AS jour,
count(*) AS commandes,
sum(amount) AS revenu
FROM boutique.public.orders
WHERE created_at >= now() - interval '1 day'
GROUP BY 1;Rien n'est matérialisé à votre place — c'est le SQL qui décide où vont les résultats. Qualifiez une table avec un projet et elle est créée dans le vrai Postgres de ce projet, aussitôt lisible par votre application. Un simple SELECTqui n'écrit rien reste valide; son résultat est journalisé sous forme d'aperçu, puis ignoré, exactement comme une requête à l'invite psql.
Un exemple entre projets — joignez deux bases que vous possédez et ajoutez le résultat à une troisième :
INSERT INTO entrepot.public.commandes_clients
SELECT o.id, o.amount, c.segment
FROM boutique.public.orders o
JOIN crm.public.customers c ON c.id = o.customer_id
WHERE o.created_at >= now() - interval '1 day';Isolé par construction
Exécuter du SQL arbitraire selon une planification ne fonctionne que si chaque exécution est confinée. Chaque exécution s'effectue dans son propre moteur en mémoire avec un plafond de mémoire et un délai, et avec l'accès au système de fichiers local désactivé — une requête atteint vos bases Postgres par le réseau, mais un read_csv ou un COPY … TOvisant un fichier de l'hôte retourne une erreur de permission claire. Une exécution ne voit que les bases que votre propre compte possède; les données d'un autre client ne sont jamais accessibles. Une agrégation hors de contrôle est tuée par OOM dans son propre cgroup, jamais sur la machine hôte.
Vous gérez le reste depuis le tableau de bord : Exécuter pour tester sans attendre, Suspendre et reprendre, un bouton Annuler sur une exécution en cours, et un historique qui marque chaque exécution Réussie, Échouée, Délai dépassé ou Annulée.
Le volet souveraineté
La raison pour laquelle cela compte au-delà du confort : toute la boucle reste au Canada. Vos données ne quittent jamais votre compte pour être traitées. Aucun orchestrateur externe ne détient les identifiants de votre base, aucun exécuteur de tâches hébergé aux États-Unis n'a une copie de vos lignes, aucune facture de sortie pour déplacer les données vers un nuage d'analytique et les ramener. La requête s'exécute à quelques millisecondes de la base qu'elle lit, sur une infrastructure de propriété canadienne hébergée à Montréal — la même posture que l'Atelier de données et le reste de la plateforme.
Les requêtes planifiées sont offertes sur tous les forfaits, Démarrage inclus. Ouvrez Calcul → Requêtes planifiées pour écrire la vôtre, ou lisez le guide complet.