> ## Documentation Index > Fetch the complete documentation index at: https://docs.parable.work/llms.txt > Use this file to discover all available pages before exploring further. # Pipelines > Store any expensive query a Parable's Pages read as a Pipeline, produced once and kept, so every Page opens fast. # Pipelines A Pipeline is a Plot whose result is produced once and kept, instead of computed again for every reader. Turn the Pipeline switch on beside a Plot's results, or set the Plot's requiresReportingRun field to true through the Piece tools; that field is the Pipeline switch. A Plot that is not a Pipeline reads the Pools live each time it runs, and a Plot read as a view runs its SQL again inside every read that names it. Parables are product experiences, and speed is part of the product: a Page that keeps its reader waiting has failed, however right its numbers are. So make a Pipeline of any query that is expensive to run on every read, and judge expense with what you know about query cost: how much data it scans, how many tables it joins, how much it aggregates, whether it calls a model, and how many Plots and Pages would repeat it. A measured read that is slow settles the question. Also make a Pipeline of any number everyone must read the same way. Stored data is honest about its age: every reader sees when the data they read was produced, and people with access can refresh it. A Pipeline's output is as fresh as its last Report run, so schedule runs as often as the Pages need. Measure when you can. While the person records in the editor's Performance tab, each of their Messages carries the recording, and you can read it: every Page load, switch, Page open and press, with each Plot read's time, rows and size, whether it was live or stored, and where its server time went. A live read that held a Page back on each open is the measurement that settles the question, and the recording's hints name it. Read it before recommending a Pipeline, and say which reads you measured. When a Message carries no recording, ask the person to turn on Record in the Performance tab and open the Page again. A Pipeline runs as part of a Report run. Each run captures the published Version and every Pipeline's SQL and inputs, keeps the moment it started, runs the Pipelines against the Provider Pool as of one time, and stores each Pipeline's output with its row count, cost, and provenance. A Pipeline reads Provider, Plot and artifact tables at that time, a Pipeline of another Parable from that Parable's newest Report run completed by that time, each Workspace table (such as workspace.users) once when the run plans it, and each Pane's saved rows by name (`parables..`, This Parable's over the Parable's Default, and `_by_actor` for every team's) as they were when the run started, never a person's own; Prepare refuses a Pipeline that reads anything else, such as information\_schema, and names the table. Readers then see as Current the output in the newest completed Report run of the Release's major line, or choose a specific run in the Report picker. A minor Release reads the runs of earlier Releases in its major line. A major Release needs a run of its own. A Pipeline starts from the Provider Pool. A Pipeline keeps the same contract as any Plot: the Pane's Perception declares its parameters and columns, and its SQL must return exactly those columns with those types. Select the declared columns by name and cast them to the declared types. SELECT \* stores every Provider column, and every read of that output fails against the contract. A Pipeline can read another Pipeline of the same Report: the run is a graph, so a Pipeline runs after the Pipelines it reads and reads what they wrote in that run. Pipelines that read each other in a cycle are refused. A Pipeline can also read Plots of its Parable that are not Pipelines: the run reads each as a view of its SQL from the captured Version, so a chain of plain Plots feeding one Pipeline stores only the result. A Provider table that has never been written, whose Provider the Workspace has not connected, or whose stream the Workspace has not turned on, reads as an empty table with its declared columns, so the run still completes and its Pipelines store no rows for that input. A hierarchy, such as everyone below each manager at any depth, is a Pipeline with a recursive query: WITH RECURSIVE, its two terms joined by UNION. UNION stops when an iteration adds no new row, so a loop in the data, such as a person listed as their own manager, ends; UNION ALL is refused with QL-PL-014. Order the output by the column readers look it up by, so each reader's lookup reads few rows, and let plain Plots read it for each reader. 1. Work down from the experience. For each Page, list what a reader must see first and the Plots behind it, then trace each Plot to the queries it needs. Store each expensive one as a Pipeline. Leave live only cheap reads over stored outputs: reader-specific filters, per-person settings, and small lookups. 2. Declare each Pipeline's columns in the Pane's Perception, write SQL that returns exactly those columns, and preview the Plot against real data. 3. Turn on the Pipeline switch and Preview the Report on your Changes: every Pipeline runs in order on a sample, and the Pages read its outputs when you choose it in the Refresh menu (see the Reports Power). Fix what reads wrong and Preview again. 4. Publish the Version, then run a Report or schedule one, and wait for it to complete. A Report needs no setup. Until a Version's first run completes, its Pages show Power on Parable. Read each Pipeline through Current and through that run, and compare the row counts with the run's results. 5. After changing a Pipeline's SQL or columns, publish and run again; Current reads only outputs that fit the published definition. A good Pipeline returns exactly its declared columns, completes on a Workspace that lacks some Providers, is read through Current by the plain Plots and Panes that use it, and never fakes a result: an output that does not fit its definition is unavailable, not substituted. A good Parable opens every Page fast on the Workspace's full data, because its heavy work comes from stored outputs. Related Powers: Plots, Reports, Pages, Perceptions, Providers, Publishing. Find each by its title; do not guess stored names. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.