> For the complete documentation index, see [llms.txt](https://help.tellius.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tellius.com/tellius-6.4/kaiya/kaiya-missions/how-to-create-a-kaiya-mission/keep-results-in-an-internal-datasource.md). # Keep results in an internal datasource Keep a Mission's results from run to run in a storage space Tellius manages, so several Missions and an App can share data without a warehouse. Missions and Apps don't keep data on their own. A Mission run's tables stay in its conversation, and nothing a person types into an App is saved. An **internal datasource** is a storage space that Tellius manages for you. A Mission can keep its results there run after run, an App can read them, and an App's buttons can write to it, for example to record a note or an approval. Use it to link several Missions and an App when you don't have a data warehouse, or another storage system connected to Kaiya, to hold the data in between. Kaiya sets it up for you in the conversation. There is no separate screen to configure it. {% hint style="success" %} **Internal datasource or a connected warehouse such as Snowflake?** Use a warehouse you have connected to Kaiya, such as Snowflake, when the results belong with the rest of your company's data, other tools need to read them, or they must stay in your own systems. Use an internal datasource when you have no such storage connected, or when the data only serves this use case, such as run history, notes, statuses or approvals. If you name a warehouse table or a connected system in your request, Kaiya writes there instead. See [Using connected systems in Kaiya](https://help.tellius.com/kaiya/tellius-mcp-server/using-connected-systems-in-kaiya). {% endhint %} ### Step 1: Ask Kaiya to keep the data Say what should be kept and who will use it, in the Mission's conversation. For example: * *"Keep each run's coverage counts so I can see the history in an App."* * *"Let territory managers record an override for each account in the App, and keep it."* * *"Store the latest scorecard so the App always shows the newest run."* Kaiya first looks for an internal datasource you own, or that was shared with you, that fits this use case. A datasource shared with you as read-only can't be stored into. ### Step 2: Answer the Internal datasource question Kaiya always asks before it creates an internal datasource, even when your request already says to keep the results. A question with the header **Internal datasource** says what the datasource will hold, and offers answers such as: * **Create '*****Coverage history*****' (ClickHouse)** * **Create '*****Coverage history*****' (Postgres)** * **Use '*****existing name*****'**, for each existing datasource that could fit Kaiya names the datasource for what it holds, recommends one engine first and says why in one line. Choose an answer and select **Submit**. One answer creates one datasource, so Kaiya asks again if the use case needs a second one. #### Postgres or ClickHouse The engine is fixed when the datasource is created. | | **Postgres** | **ClickHouse** | | ----------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------- | | **Best for** | Many small, specific changes: notes, approvals, overrides, statuses | Large result sets that a Mission writes and an App analyzes | | **Typical data** | What an App's users type in | Run-by-run snapshots, event or record history, wide results | | **What App buttons can do** | Add, change and delete rows | Add rows only | | **Several writes in one step** | All or nothing | Applied in order, one after another | | **Rows per store (a guide, not a limit)** | Up to about 20,000 | Up to about 100,000 | {% hint style="info" %} **Need both?** One use case can use two datasources: the Mission's history in ClickHouse and the App's notes in Postgres. To move to the other engine later, ask Kaiya to create a new datasource and point the Mission and App at it. Rows don't move on their own. Ask Kaiya to copy them across if you want to keep the history. {% endhint %} ### Step 3: Choose how much history to keep Kaiya adds a step to the Mission that keeps an earlier step's rows in a table. The table's columns are the columns of that earlier step. The table is created on the first run, gains a column when the step gains one, and never loses or changes a column. * **Every run:** each run adds its rows to the table and keeps the ones before it (append). Kaiya stamps each row with the run time. * **Only the latest:** each run replaces the table's rows with its own (replace). For anything more, such as one current row per account, several tables in one step, or changing and deleting rows, Kaiya writes a short Python step that saves the data. It can also keep only the latest few runs, or skip rows the table already holds. Tell Kaiya how much history you need when it isn't clear from your request. ### Step 4: Publish and run the Mission Only the **published** Mission's runs store rows: a run from **Run**, a scheduled run, or a run you ask Kaiya for after publishing. While you build and check the draft, the step only prepares the tables and reports what it would have written, so your history never fills up with test runs. Kaiya tells you this as you build. To have data to show in an App, publish the Mission and run it, then build the App. See [How to create a Kaiya Mission](/tellius-6.4/kaiya/kaiya-missions/how-to-create-a-kaiya-mission.md). Each result is written once. When a run reuses an earlier result because the step behind it hasn't changed, the step reports that the table already holds this result, and writes nothing. That isn't a failure. ### Read and write from an App * **Reading.** An App reads the table through live cells, so it reads the table again each time it opens and every new run appears without a refresh. See [Live data in Apps](/tellius-6.4/kaiya/kaiya-apps/live-data-in-apps.md). * **Latest run or all runs.** When the table keeps every run, the App shows the latest run unless you ask for history. Charts that show change over time use every run. Kaiya labels which one each view shows, for example **Latest run** or **All runs**. * **Writing.** An App's buttons can write to the datasource, for example **Add note**. On Postgres, a button can add, change or delete rows. On ClickHouse, it can only add rows. Every click asks the person using the App to confirm before anything is written, and they write with their own access. After the write, the App shows the new row. {% hint style="info" %} **Combining it with a Business View.** An internal datasource isn't a Business View. Kaiya queries it separately and combines the two results in a Python step when a view needs both. {% endhint %} ### Sharing and remixes * **Sharing.** When you share a Mission or an App, its internal datasources are shared with it, with write access. The people you share it with can run the Mission and use the App's buttons. It is still one set of tables, so their runs and notes appear for you too. * **Remixing.** A remixed copy still points at the original's datasource. Before the copy runs or is saved, Kaiya asks an **Internal datasource** question: **Create a separate internal datasource for this copy** (recommended, so the copy's runs stay apart from the original's) or **Keep writing to '*****name*****' (shared with the original)**. If you choose a separate datasource, Kaiya asks which engine to use. A copy of a copy is asked again. Reading someone else's datasource never needs this choice. See [Remix a Mission shared with you](/tellius-6.4/kaiya/kaiya-missions/how-to-create-a-kaiya-mission/remix-a-mission-shared-with-you.md). ### Good to know * Tellius makes the writes with the datasource's own sign-in. The Mission and the App never hold a password or a connection. * Kaiya writes the SQL for the datasource's engine, so you don't need to know the difference between Postgres and ClickHouse. * The row counts in the engine table are guides. Above them, the rows are still stored and the step notes it. For very large tables, ask Kaiya to aggregate first or use ClickHouse. ### Related pages * [How to create a Kaiya Mission](/tellius-6.4/kaiya/kaiya-missions/how-to-create-a-kaiya-mission.md) * [How to create a Kaiya App](/tellius-6.4/kaiya/kaiya-apps/how-to-create-a-kaiya-app.md) * [Live data in Apps](/tellius-6.4/kaiya/kaiya-apps/live-data-in-apps.md) * [Using connected systems in Kaiya](https://help.tellius.com/kaiya/tellius-mcp-server/using-connected-systems-in-kaiya) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.tellius.com/tellius-6.4/kaiya/kaiya-missions/how-to-create-a-kaiya-mission/keep-results-in-an-internal-datasource.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.