Publieke testfase We zitten in een publieke testfase — kijk gerust rond, maar bestellen kan nog niet. Bestellen kan vanaf 1 oktober 2026. Reserveer je plek →

Jobs & Pipelines: van ruwe tabellen naar rapporten, op schema

Jobs & Pipelines is de plek waar aan je data gewerkt wordt terwijl jij niet kijkt. Een pipeline is SQL die tabellen in je warehouse bouwt uit je sitedatabases; een job zet pipelines, SQL-scripts, dashboardverversingen en meldingen op volgorde en draait ze op schema. Beide staan in één lijst in Manage — zijbalkgroep "Data Warehouse", naast Databases, Runs en Dashboards — en elke run staat op de Runs-pagina. Inbegrepen bij elk abonnement, met het budget van je warehouse-tier.

Een pipeline is SQL

Er is geen diagram om te tekenen. Een pipeline is een map met hoogstens 20 .sql-bestanden (elk 64 KB) die je bewerkt in dezelfde CodeMirror-editor als de Databases-werkbank, waarbij de databases die je mag lezen onder hun naam aanvullen (shop. vult aan). Elk bestand bevat een willekeurig aantal met ; gescheiden statements, en er zijn precies twee vormen:

CREATE OR REFRESH TABLE [warehouse.]naam [KEY (kol, kol)] AS <select>;
CREATE OR REFRESH SOURCE VIEW naam [FROM database] AS <select>;
  • TABLE wordt gematerialiseerd in het warehouse (MariaDB of PostgreSQL — wat de doeldatabase ook is). Met KEY worden de rijen op die kolommen ge-upsert, zodat een nachtelijke run alleen herschrijft wat veranderde; zonder KEY wordt de tabel elke run opnieuw gebouwd. De SELECT mag source views en andere tabellen van de pipeline lezen, tabellen van het warehouse, en elke tabel van een sitedatabase als database.tabel.
  • SOURCE VIEW draait op de sitedatabase, in haar eigen dialect, via dezelfde alleen-lezen login als de werkbank, en wordt naar het warehouse gestreamd als stagingtabel. Zet je WHERE daar, zodat alleen de rijen reizen die je nodig hebt. Ze mag niets lezen wat de pipeline zelf definieert.

Bronnen zijn elke sitedatabase, altijd alleen-lezen; het doel is altijd een warehouse-database. De afhankelijkheidsgraaf en de lineage worden door de server afgeleid uit de SQL: elke naam na FROM of JOIN die de pipeline definieert is een afhankelijkheid, dus de bouwvolgorde volgt uit wat je schreef, een lus wordt geweigerd, en bouwen in twee warehouses ook. Het paneel onder de editor toont Problems (als bestand:regel, ververst terwijl je typt), de Pipeline graph — knopen "Source view" en "Materialised table" — en Tables.

Knoppen in de kop: Run file toont een voorbeeld van het open bestand zonder iets te schrijven — de eerste 50 rijen per tabel, gebouwd uit 200 rijen per bron; Dry run haalt de hele pipeline door een run die niets schrijft; Run pipeline bouwt hem echt en verschijnt op Runs. Een job kan een pipeline draaien met Full refresh, wat elke incrementele tabel die ene keer opnieuw bouwt. Hoogstens 20 pipelines per account.

Een job

Een job is een lijst stappen die één voor één, op volgorde, draaien. Elke stap kan afhangen van eerdere stappen (depends_on: draai als die stap slaagde, mislukte, of altijd), en er zijn acht soorten:

  • Run a pipeline — met de optionele full-refresh-schakelaar;
  • Run SQL — tot 50 statements op een warehouse-database, op volgorde, stoppend bij de eerste fout;
  • Refresh a dashboard — draait elk paneel en houdt de antwoorden warm, zodat de pagina meteen opent;
  • Send an email — alleen aan leden van dit account; altijd, alleen als de job slaagt of alleen als hij mislukt; onderwerp en tekst mogen {{job.name}}, {{run.status}}, {{run.duration}}, {{run.url}} en {{step.<key>.rows_written}} (ook rows_read, status) gebruiken; optioneel een CSV van een query als bijlage, tot 5 MB of 50.000 rijen;
  • Call a webhook — een van de endpoints op je Integraties-pagina, standaard alleen bij mislukken;
  • Wait — tot 300 seconden;
  • Run another job — en er optioneel op wachten;
  • Check — een ja/nee-vraag over iets wat een eerdere stap rapporteerde (geschreven rijen, gelezen rijen, status, opgewarmde panelen…) of over de eerste cel van één alleen-lezen SELECT, met is, is not, is more than, is at least, is less than, is at most, is empty, is not empty — en de stappen erna gekoppeld aan het antwoord.

Een job draait als de persoon die hem het laatst heeft opgeslagen, en reikt precies zo ver als die persoon met de hand zou kunnen; een pipeline erin draait als haar laatste auteur. Verlaat die persoon het account, dan stopt de job totdat iemand met toegang hem opnieuw opslaat.

Triggers en gelijktijdigheid

Een job draait Only when I run it ("Runs when you press the button"), On a schedule, of After another job succeeds. Schema's zijn er als voorinstellingen — elke paar minuten of uren (met een van–tot-venster en de weekdagen waarop het geldt), elk uur, elke dag, week of maand — of als een eigen cron-expressie, gelezen in de tijdzone die jij kiest. Het kortste interval is 5 minuten op Pro en 1 minuut op Business. Eén run tegelijk per account: komt een geplande run binnen terwijl een andere nog loopt, dan slaat de job de nieuwe run over (vastgelegd als skipped) of zet hem in de wachtrij, met hoogstens drie wachtenden. 500 runs per dag per account.

Budgetten per run

Elke run wordt gehouden aan het plafond van het account — het budget van zijn warehouse-tier; een job mag zijn eigen budget verlagen, nooit verhogen. Op Starter (Warehouse XS) en Pro (S): 15 minuten, 500.000 rijen, 512 MB uit bronnen gehaald, 512 MB geheugen. Op Business: 60 minuten, 5 miljoen rijen, 2 GB, 1 GB — het gepubliceerde budget, bovenop Warehouse M. Warehouse L op Starter of Pro: 60 minuten, 5 miljoen rijen, 2 GB, 2 GB. Een run die zijn budget overschrijdt wordt gestopt en zegt dat. Elke tier bevat job-minuten per maand — 30 op XS, 120 op S, 600 op M, 2.000 op L — en runs daarboven worden op rekentijd gemeten. Runs en hun logs worden 90 dagen bewaard.

De Runs-pagina

Runs toont "elke eenheid rekenkracht die dit account heeft gebruikt" — jobruns, pipelineruns, dashboardverversingen, editorstatements, API- en MCP-queries, imports — met de gemeten tijd opgeteld over het venster. Metered compute is tijd; "Nothing here is a bill." Filter op soort, status, wie het startte en datums; open een run voor de Steps, de Log-lade per stap of voor de hele run, en Stop er een die nog loopt.

Limieten

De gepubliceerde limieten zijn het standaardaanbod:

  • 20 jobs en 20 pipelines per account, 20 stappen per job, 20 bestanden van 64 KB per pipeline;
  • schema's vanaf elke 5 minuten (Business en Warehouse L: elke minuut), één run tegelijk, drie in de wachtrij, 500 runs per dag;
  • per run 15 min / 500.000 rijen / 512 MB / 512 MB geheugen op Starter en Pro (Business: 60 min / 5 mln rijen / 2 GB / 1 GB; Warehouse L: 60 min / 5 mln rijen / 2 GB / 2 GB);
  • job-minuten per maand inbegrepen: 30 op Starter, 120 op Pro, 600 op Business, 2.000 op Warehouse L — runs daarboven worden op rekentijd gemeten;
  • runs 90 dagen bewaard; jobruns worden gemeten in rekentijd, zichtbaar op Runs voordat er iets gefactureerd wordt.

Meer nodig? Neem contact op — ruimere limieten zijn op aanvraag beschikbaar, tegen betaling.

Vanuit een script of je AI-assistent

Jobs en pipelines zitten in de API en de MCP-server, achter de opt-in scope data:

  • GET / POST /api/v1/jobs, GET / PUT / DELETE /api/v1/jobs/{id}, POST /api/v1/jobs/{id}/run, GET /api/v1/jobs/{id}/runs, GET /api/v1/jobs/runs, POST /api/v1/jobs/runs/{id}/cancel;
  • GET / POST /api/v1/pipelines, GET / PUT / DELETE /api/v1/pipelines/{id}, POST …/compile (puur en gratis — problemen met bestand en regel), POST …/preview (schrijft niets), POST …/run, GET …/runs.

Een assistent krijgt list_jobs, create_job, run_job, get_job_runs, list_pipelines, create_pipeline, preview_pipeline en run_pipeline — de hele pipeline-grammatica staat in de beschrijving van het gereedschap create_pipeline, dus een gekoppelde assistent kan een pipeline voor je schrijven en controleren of hij compileert voordat hij zegt dat het klaar is. Een run die als skipped of queued wordt beantwoord is het platform dat bewust weigert, geen fout.