--- title: "AI-Built App Data Storage: What Survives a Change" url: https://www.insulin.dev/blog/ai-built-app-data-storage/ canonical: https://www.insulin.dev/blog/ai-built-app-data-storage/ type: Blog description: "An AI-built app that stores data gets its own database. What code changes, failed migrations, restores and deletes do to it, and a snapshot to take first." --- # AI-Built App Data Storage: What Survives a Change > Canonical HTML version: https://www.insulin.dev/blog/ai-built-app-data-storage/ 1. [Home](/) 2. / 3. [Blog](/blog/) 4. / 5. AI-Built App Data Storage: What Survives a Change # AI-Built App Data Storage: What Survives a Change An AI-built app that stores data gets its own database. What code changes, failed migrations, restores and deletes do to it, and a snapshot to take first. ![Qiuyang Luo](/authors/qiuyang-luo.jpg) Qiuyang Luo Sep 28, 2026 ![AI-Built App Data Storage: What Survives a Change](/images/blog/ai-built-app-data-storage/hero.png) Explore AI Summary [![](/logos/company/openai.svg)](https://chat.openai.com/?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fai-built-app-data-storage%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Custom%20Apps%2C%20Workspace. "Summarize with ChatGPT")[![](/logos/company/anthropic.svg) ](https://claude.ai/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fai-built-app-data-storage%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Custom%20Apps%2C%20Workspace. "Summarize with Claude")[![](/logos/company/gemini.svg)](https://www.google.com/search?udm=50&aep=11&q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fai-built-app-data-storage%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Custom%20Apps%2C%20Workspace. "Summarize with Gemini")[](https://www.perplexity.ai/search/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fai-built-app-data-storage%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Custom%20Apps%2C%20Workspace. "Summarize with Perplexity") Table of Contents - [Where does an AI-built app keep its data?](#where-does-an-ai-built-app-keep-its-data) - [What happens to the data when the app changes?](#what-happens-to-the-data-when-the-app-changes) - [What does App History restore?](#what-does-app-history-restore) - [What happens when you delete an app?](#what-happens-when-you-delete-an-app) - [How do you take a limited snapshot before a change?](#how-do-you-take-a-limited-snapshot-before-a-change) - [What should you check before changing a live app?](#what-should-you-check-before-changing-a-live-app) - [Frequently asked questions](#frequently-asked-questions) - [Takeaways](#takeaways) _AI-built app data storage is the database an AI-built app keeps for what people enter into it. In Insulin, a code change does not automatically reset that data but can change it, a restore brings back code rather than data, and deleting the app means treating the data as gone._ * * * An intake form built with AI on Monday can be a system of record by Friday. Once a team is filling it in, whoever built it has a new question: what happens to those records when the app changes, or when someone deletes it? Insulin’s documentation answers that event by event, and not every answer is the one a version history suggests. Saving new code doesn’t automatically reset the data, but it can change it. A save whose migration fails can still leave changes behind. Restoring an earlier version brings back its code, not its data. Deleting the app makes the data unavailable. What follows is each event in turn, then a limited snapshot to take before you change an app people rely on, including what that snapshot can’t capture. ## Where does an AI-built app keep its data? **In a database of its own.** Ask Insulin’s app builder for an app that has to remember what people enter, such as a request tracker, a to-do list or an intake form, and it gives the app a database separate from every other app’s. The database is created the first time the app needs it; there is nothing to set up. It is also separate from your Fours data, which an app can only read: it reaches your marketplace data through a fixed list of read operations, none of which writes. So everything below concerns the app’s own database, not your marketplace records. As for cost, database storage is not metered, as [Insulin’s usage-based pricing page](/pricing/) notes beside the file storage that is. ## What happens to the data when the app changes? **It stays, but it isn’t frozen: each save that changes the code runs the app’s migration again, and the migration may change the data already stored.** **An app’s migration is** its own setup step. The documentation doesn’t list which changes alter stored data, only that the migration may, so treat every code change to a live app as one that can. Event The app’s code The data the app has stored The app first needs to store something — Its own database is created, with nothing to set up You save new code Saved, and snapshotted as a new version Not automatically reset; the migration runs again and may change it The migration fails during a save The save is refused, and the app keeps its previous version Changes the migration made before it failed are not undone You restore an earlier version A new version with that version’s code, reviewed and compiled like any other save Not rolled back or automatically reset; the restored version’s migration runs again and may change it You delete the app The app is permanently removed Unavailable, and removal of its database is scheduled. Treat the data as gone Three rows deserve a second look. **“Not reset” is not “unchanged.”** A save leaves the data in place, which is the reassuring half. The other half is that the migration runs on every save that changes the code, and a change you think of as cosmetic, such as a renamed button or a moved chart, is still a code change. **A failed migration can still leave changes behind.** When the migration fails, the app keeps its previous version, but whatever the migration changed before it failed stays changed. The version that carries on running may be reading data the failed migration already touched, so check the data after a refused save, not only after one that went through. **A restore brings back how the app worked, not what the records said.** Restoring runs the restored version’s migration again, over the data as it is now. If a change altered records, restoring the earlier code does not put them back. ## What does App History restore? **The code of an earlier version, saved as a new version; never the data.** The builder header carries a **History** button, which opens **App History** for the app: - **Every save that changes the app’s code is snapshotted.** Recompiling the same source or editing only metadata doesn’t mint a version, so the list is a record of the app actually changing. - **The newest 50 versions per app are kept**, so the history reaches back 50 versions, not to a date. - **You can preview any version, then restore it** behind a two-step confirmation. - **Restore rolls forward; it never deletes.** The restored version goes through the full safety-review and compile pipeline like any other save, and nothing between the snapshot and now is removed, so a restore is itself undoable by restoring the version you were on. - **Read-only roles can list and preview versions, but cannot restore.** On a shared app, those are the User and Viewer roles. That makes App History a history of the code. It can answer “how did the app work before Tuesday’s change?” It cannot answer “what did the records say before Tuesday’s change?”, because a restore never rolls data back. The documentation describes no history of the data itself, so the answer to the second question is whatever you saved before the change. ## What happens when you delete an app? **The app and its data become unavailable, and removal of the app’s database is scheduled. The documentation’s advice is plain: treat the data as gone.** **Delete App**, on the right-click menu of an app in the Custom Apps sidebar, permanently removes the app, and the documentation describes no way to bring a deleted app or its records back. Who can delete depends on the app: - **A personal app:** only its owner. - **An organization app:** its owner, or anyone who holds **Admin** on it. The organization ADMIN role doesn’t count by itself; an org ADMIN who doesn’t own the app needs an Admin share on it. If an organization app is headed for deletion only because its owner is moving on, the owner can transfer it to another organization ADMIN instead. Otherwise, take the snapshot below first, and delete only when nobody needs the records. ## How do you take a limited snapshot before a change? **Export what the app displays with Download CSV, one table or chart at a time, and label the files as reference copies.** **A limited snapshot is** a set of CSV files recording what an app’s tables and charts showed at one moment. It lets you compare before and after, but it is not a complete export of the app’s database and not a way to roll the app back, because Download CSV exports only the rows currently shown, using the columns currently visible. 1. **Expose every required column.** If a table has a **Columns** picker, tick every column you need before you export. The picker is opt-in, appearing only on tables the app was built with a column picker on, so a table without one exports the columns it shows and no others. 2. **Confirm that every required row is displayed.** Clear any filter or search the app applies, make sure every row you need is shown in the table, and afterwards check each file’s row count against what you expect. 3. **Export every relevant table or chart separately.** Each table with data carries its own **Download CSV**. On a chart plotted over time, the **≡** button in the chart’s header holds a **Download CSV** that saves the data behind the chart, greyed out when the chart has no data. The documentation describes no whole-app export, so one app can mean several files. 4. **Label the files as reference copies.** Name each for the app, the table or chart, and the date, and keep them together. Mark them as reference copies of what the app displayed, not a complete database export and not a rollback mechanism: the documentation describes no way to load a CSV back into an app. What the snapshot can’t capture: - **Anything the app stores but doesn’t display.** The files hold only what a table or chart shows. - **Anything that needs a code change to reach.** The table control is generated into each app, so an older saved app may lack Download CSV until you regenerate it in the builder, and a column no table shows can’t be exported without changing the app. Either change is a save that changes the code, so the migration runs for it too. Make it on its own, before the change you came to make, noting what the app shows before and after it. The same export is how you [check an AI-generated dashboard against your own records](/blog/verify-an-ai-generated-dashboard/); here it serves as a before-and-after reference instead. ## What should you check before changing a live app? **Whether the app keeps data, what the change will do to it, a snapshot, one change per save, and the data afterwards, including after a refused save.** As a checklist: 1. **Does the app keep data of its own?** If it remembers what people enter, it has a database, and every save that changes the code runs its migration. An app that has never needed to store anything has no database yet. 2. **Ask before you edit.** Switch the builder to **Chat** mode, which answers without touching the app, and ask what the change will do to the stored data. Treat the answer as a plan to check, not a guarantee. 3. **Take the limited snapshot.** Every required column and row, every relevant table and chart, each file labelled as a reference copy. 4. **Make one change per save.** Each save that changes the code runs the migration and adds its own version to App History, so one change per save makes it easier to tell which change touched the data, and gives each change a version to restore from. 5. **Check the data after every save, including a refused one.** Compare what the app shows with the snapshot. A save refused because its migration failed keeps the previous version, not necessarily the previous data. 6. **Restore for code, not for data.** If the new version is wrong, restore the one before it. The records are not rolled back, and the snapshot is your reference for what they said. 7. **Delete last, and on purpose.** Deleting makes the app and its data unavailable. Treat the data as gone. ## Frequently asked questions ### Does saving new code reset an AI-built app’s data? No. Existing data is not automatically reset when you save new code. But the app’s migration, its own setup step, runs again on each save that changes the code, and it may change the data already stored. ### Does restoring an earlier version bring the data back? No. A restore brings back that version’s code as a new version, not its data. Data the app has stored is not rolled back or automatically reset, and the restored version’s migration runs again and may change it. ### What happens to the data when a save fails? If the app’s migration fails, the save is refused and the app keeps its previous version. Any database changes the migration made before it failed are not undone, so check the data after a refused save as well. ### What happens to an app’s data when the app is deleted? The app and its data become unavailable, and removal of the app’s database is scheduled, so treat the data as gone. A personal app can be deleted only by its owner; an organization app also by anyone with Admin on it. ### Is Download CSV a backup of an app’s database? No. It exports the rows a table currently shows, in the columns currently visible, or the data behind one chart. Treat the files as a limited reference copy of what the app displays, not a complete export or a way to roll back. ### Does an app’s database cost extra? Database storage is not metered. Insulin’s billing documentation lists it among what is never billed, and the pricing page says the same beside the file storage that is metered. ## Takeaways - An Insulin app that remembers what people enter gets a database of its own, separate from every other app’s and from your Fours data. - Saving new code doesn’t automatically reset that data, but every save that changes the code reruns the app’s migration, which may change it. - A save refused because its migration failed keeps the previous version, and whatever the migration had already changed. - App History restores code, not data. Deleting an app makes its data unavailable: treat it as gone. - Before changing a live app, take a limited snapshot with Download CSV, labelled as a reference copy rather than a backup. An app is worth protecting from the day people start relying on it. To see what a team can build on its own data, start with [Custom Apps in Insulin](/custom-apps/); the documentation on [data an app keeps for itself](https://doc.fours.com/insulin/custom-apps/#data-an-app-keeps-for-itself) is the reference for every rule above. ## Sources Primary sources for the platform rules cited above. Last verified September 28, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure. - [Insulin Custom Apps — Fours Doc](https://doc.fours.com/insulin/custom-apps/) — A database of its own for each app that has to remember what people enter, separate from every other app's and from Fours data, created the first time the app needs it; the migration rerunning on each save that changes the code; a failed migration refusing the save without undoing its changes; a restore bringing back code, not data; deletion making the app and its data unavailable and scheduling its database's removal (treat the data as gone); App History, code-only snapshots, the newest 50 versions, the two-step Restore that rolls forward, and read-only roles; Delete App and who may delete; Transfer ownership; Download CSV, the opt-in Columns picker, the chart exports behind the ≡ button and older apps without the table control; Chat mode - [Insulin Billing: What Is Metered — Fours Doc](https://doc.fours.com/insulin/billing/metering/) — Database storage is on the list of what is never billed: not metered ## Keep reading - [Custom AppsHow to Share an Internal App with RolesAug 18, 2026](/blog/publish-a-custom-app-with-roles/) - [Custom AppsBuild an Internal Tool Without Writing CodeAug 16, 2026](/blog/build-an-internal-tool-without-code/) - [Custom AppsWhen to Build a Custom App, Not a DashboardAug 16, 2026](/blog/custom-app-or-dashboard/) - [WorkspaceAI Workspace Admin Checklist: Set Up InsulinOct 8, 2026](/blog/ai-workspace-admin-checklist/) [Browse every post on the Insulin Blog](/blog/) ### Stay Updated New posts, product updates and marketplace strategy are shared on LinkedIn as they publish. [Follow Fours on LinkedIn](https://www.linkedin.com/company/suger-inc)