The first time a founder thinks hard about their data is often the morning Base44 is down and the dashboard will not load. After the February 2026 outage and the forum threads that followed it, one question kept coming up: if the platform vanished tonight, would I still have my customers' data? It is a fair fear, and the honest answer is more nuanced than either "you're fine" or "you're doomed." Here is where your Base44 data actually lives, what the outage really proved, and how to set up a backup and recovery routine that turns a terrifying unknown into a managed risk.
Base44 keeps your records in its own managed database, encrypted at rest, and gives you two recovery tools inside the platform: deleted records stay restorable for 30 days, and Elite and Enterprise plans add point-in-time Backup & Restore for 7 or 30 days. Both live inside Base44 and both expire. A scheduled export to storage you own is the copy that outlasts them.
Where Your Base44 Data Actually Lives
When you create an entity in Base44 and the AI writes records into it, those rows land in a managed database that Base44 provisions and operates on your behalf. Base44's developer docs describe it as "a NoSQL database" that is "MongoDB compatible" (Base44 backend features), and the sub-processor directory on its security page lists Mongo (US) for "Data storage and hosting". Base44 is owned by Wix now, but the model is unchanged: you interact with your data through the SDK, the entity API and the Data tab, never through a direct database connection. There is no connection string you can paste into a database client, no dump you can run, and no replica you control. Your access to your own data is mediated entirely by the platform's API.
This is not unusual for an AI app builder, and it is not inherently unsafe. Base44 says it encrypts app data in transit with TLS 1.2+ and at rest with AES-256, and that "Encryption covers backups too." It also says it maintains "defined Recovery Time and Recovery Point Objectives aligned with industry standards, backed by frequent automated backups and documented recovery procedures", with the detailed commitments reserved for Enterprise customers' Service Level Agreements (base44.com/security, read 23 Sep 2026). The distinction that matters for your peace of mind is between three kinds of protection, and they belong to different people:
- Platform disaster recovery protects Base44 against infrastructure failures, the failed disk or lost server. Base44 runs it, and you cannot trigger it yourself.
- In-app recovery protects you against recent mistakes, inside a fixed window. Recently deleted keeps deleted records for 30 days, and on Elite, Business and Enterprise, Backup & Restore rewinds tables to a point in time. You run it, but it lives inside Base44 and it expires.
- An independent copy protects you against everything else: a loss nobody noticed in time, an overwrite on a plan without Backup & Restore, a long outage, or a decision to leave. Nobody handles that part unless you set it up.
The practical consequence is that you own your data in the legal and commercial sense, but you do not hold it in the operational sense. Holding it would mean having a copy on storage you control, that you can read without the platform's cooperation. An app built with AI prompts does not come with one, because nothing in the build flow ever prompts you to set it up.
What the 2026 Outage Revealed About the Risk
The February 2026 outage is worth understanding precisely, because it is easy to draw the wrong lesson from it. The question on everyone's mind was the one founders type into search at 2am, almost word for word: "what if Base44 goes down data is lost for good?" During the incident, apps became unreachable: dashboards would not load, logins failed, and the SDK calls that power every Base44 app timed out. For a stretch of hours, founders watched their live products serve errors to paying customers and had no way to intervene.
What did not happen is just as important. No data was deleted. When the platform recovered, the records were exactly as they had been before the outage began. This is the single most important thing to internalize: a temporary outage is an availability problem, not a data-loss problem. Your bytes were never at risk of disappearing. What was at risk was your business continuity, your customer trust, and your ability to do anything at all while the lights were off.
That distinction defines the two separate risks you actually need to plan for, and they require completely different responses. We call them the availability gap and the recoverability gap, and conflating them is why so much outage panic is misdirected.
| Risk | What goes wrong | Who can fix it | What protects you |
|---|---|---|---|
| Availability gap | App is offline; data is unreachable but intact | Only the platform | An independent read-only copy to operate from |
| Recoverability gap | Records deleted, overwritten, or corrupted | You: with Base44's tools inside their window, then only from a backup you hold | Recently deleted and Backup & Restore for recent mistakes; a scheduled export you own for the rest |
| Vendor risk | Platform shuts down or you decide to leave | You, via migration | Portable export plus a migration path |
The outage exposed the availability gap vividly, but in our work the recoverability gap is the one that actually destroys data, and it has nothing to do with Base44's uptime. It is the founder who asked the AI to "clean up the test users" and watched it delete real ones, or the bulk operation that overwrote a field across every record. The first can come back from Recently deleted if someone notices within 30 days. The second has no documented undo below the Elite plan, and on Elite only for 7 days. We wrote up one version of this failure in our breakdown of data loss when returning to a Base44 app, and in the cases we see, the common thread is that nobody held a copy outside the platform. If you want the deeper analysis of the structural exposure, our Base44 vendor lock-in deep dive covers what is portable and what is not.
How to Back Up and Export Your Data Today
You do not need a migration or an engineering team to get a recoverable copy of your data this week. When founders ask us how to base44 backup my app data the right way, the honest answer is that you need a routine, not a one-time export. Start with what Base44 already keeps, then add one of three tiers of backup you own. The right tier depends on how much customer data is at stake and how much you can tolerate losing.
What Base44 already keeps for you (check your plan)
The platform's own safety net changed in 2026. On 20 July Base44 added automatic data snapshots for Enterprise workspaces, on 1 August it extended them to the Elite plan with 7 days of history, and on 17 September it renamed the feature Backup & Restore (Base44 product changelog). On Elite, Business and Enterprise, the Data tab's Backup & Restore view shows what your tables held at an earlier point, downloads a table as CSV, and restores one table or all of them. A restore keeps record IDs, sends records created after that point to trash, and can itself be undone (Backup & Restore docs).
Know its edges before you lean on it. Backups "start from the moment the feature becomes active on your plan", so upgrading after an accident does not bring back what you already lost. They cover table records only: an uploaded file "is not part of the backup", and your app's users "are left out of backups entirely". Below Elite, the built-in net is Recently deleted, which holds deleted records for 30 days and does nothing for records that were edited rather than removed. None of it is a copy you hold, which is what the three tiers below are for.
The manual export (for small or pre-launch apps)
Base44's Data tab lets you export each table to CSV. For an app with a handful of entities and no live customers yet, this is genuinely enough as a starting point. Export every entity, drop the files in a dated folder in cloud storage you own, and repeat it on a calendar reminder. The weakness is obvious: it depends on a human remembering, and humans forget. A manual-export routine competes with everything else on a busy founder's calendar, so treat this as a stopgap, not a plan.
The automated export (for any app with real users)
The reliable approach is a scheduled backend function that reads every entity through the SDK and writes the records out as JSON or CSV to external storage you control. A daily or weekly cron triggers it, it iterates each entity, and it pushes the serialized records to an S3 bucket, a Google Drive folder, or even a Google Sheet that lives entirely outside Base44. Once it runs, backups happen whether or not anyone remembers, which is the entire point. This is the version we build for clients, and it typically takes a couple of hours to set up correctly, including handling pagination so large entities export completely rather than truncating at the first page.
The continuous replica (for high-stakes data)
For apps where losing even a day of data would be a real problem, the strongest pattern is a dual-write or near-real-time replica: every write to Base44 is mirrored to an external Postgres or Supabase database you own. This gives you a live, queryable copy outside the platform at all times. It is more work to build and maintain, but for fintech, healthcare, or anything where the data is the business, it is the only posture we are comfortable recommending. If you are in a regulated space, pair this with our guide to Base44 HIPAA and GDPR compliance, since backup retention and recovery are explicit obligations there. It also doubles as a head start if you ever decide to migrate, since the data is already living in a portable store.
| Backup tier | Best for | Effort to set up | Recovery point |
|---|---|---|---|
| Base44 Backup & Restore (built in) | Recent mistakes on Elite, Business or Enterprise | None, it runs automatically | Any point in the last 7 (Elite) or 30 (Business and Enterprise) days, held inside Base44 |
| Manual CSV export | Pre-launch, few entities | Minutes, but easy to forget | Whenever you last remembered |
| Automated scheduled export | Any live app with users | A couple of hours, then hands-off | Last cron run (daily/weekly) |
| Continuous external replica | Fintech, healthcare, high-value data | A few days, plus maintenance | Near-real-time |
Whichever tier you choose, the rule that makes a backup real is that it lives somewhere Base44 cannot touch. A copy stored back inside the platform is not a backup; it is a second thing that disappears in the same outage. That is not a knock on Backup & Restore, which is a real undo for recent mistakes. It sits behind the same account and the same outage as the data it protects. The storage you own is what converts an anxious "I hope they have my data" into a calm "I have my data."
Can You Recover Deleted or Lost Records?
It depends on what happened, how long ago, and which plan you are on. Base44 has two recovery tools for table data, and both have hard edges:
| What went wrong | Free, Starter, Builder, Pro | Elite | Business and Enterprise |
|---|---|---|---|
| Records deleted | Restore from Recently deleted within 30 days | Recently deleted (30 days), or Backup & Restore to a point in the last 7 days | Recently deleted (30 days), or Backup & Restore to a point in the last 30 days |
| Records overwritten by an AI edit or bulk update | No documented undo | Backup & Restore, last 7 days | Backup & Restore, last 30 days |
| Uploaded files and your app's users | No documented recovery | Not in Backup & Restore | Not in Backup & Restore |
| Anything older than the window | Only from an export you hold | Only from an export you hold | Only from an export you hold |
Recently deleted comes from Base44's data management docs, which name no plan requirement for it; the rest comes from the Backup & Restore docs, both read 23 Sep 2026. Those docs describe the 30-day window for deleted records, including a table cleared with "Delete all records". They say nothing equivalent for "Delete entire table", so treat a deleted table as gone unless you exported it.
Inside the window, recovery is a few clicks. Outside it, or for an overwrite on a plan without Backup & Restore, the only thing standing between a destructive operation and permanent loss is whether you had a backup of your own from before it happened. One more edge: Base44 keeps two separate histories. Version History in the editor is for your app's code and design, and Backup & Restore is for your data, so rolling back a bad AI change to your code is a different operation from rolling back what that change did to your records.
If you do have an export, base44 data loss recovery is mechanical and reassuring. We read the missing or correct records from your most recent backup and re-import them through the SDK, restoring the entity to its prior state. The freshness of your backup sets the ceiling on how good the recovery can be: a weekly export means you can lose at most a week, a daily export means at most a day, and a continuous replica means you lose almost nothing. The work is straightforward; the data has to exist somewhere for us to put it back.
If the window has passed and you do not have an export, your options narrow to one: ask platform support whether they can recover something from Base44's own disaster-recovery backups. Sometimes they can, and sometimes the timeline is too long or the answer is no, because those backups are designed to protect the platform from disasters, not to give individual customers a restore for a record they deleted on purpose five weeks ago. Below Enterprise there is no SLA behind that request, since Base44 reserves its detailed recovery commitments for Enterprise customers' Service Level Agreements, which we cover in our note on the absence of an SLA and the outage risk it creates. Counting on platform support as your recovery plan is the same as having no recovery plan with extra steps. The lesson every founder eventually learns, ideally before rather than after a loss, is that recoverability is something you build in advance or do not have at all.
Building a Real Disaster-Recovery Plan
A backup is a file. A disaster-recovery plan is knowing exactly what you do when something breaks, before it breaks. Across the data-safety plans we build for live Base44 apps, the same five questions separate a plan that works from a folder of CSVs nobody can use. In the words of the lead engineer at Base44Devs, a backup you have never tested is just a hope with a file extension. We call them the five recovery questions, and answering all five is the difference between resilience and false comfort.
The first is what you back up: every entity, including the small reference tables people forget, plus any uploaded files (Base44's Backup & Restore does not include them) and the configuration that defines your schema. The second is how often: matched to how much data you can afford to lose, which for an app with paying users usually means daily, not weekly. The third is where it lives: storage you own and can reach without Base44, ideally with a copy in a second location. The fourth, and the one that gets skipped, is whether the restore actually works: an untested backup is a guess, so we periodically restore into a scratch environment to confirm the export is complete and re-importable. The fifth is who does what during an incident: a one-page runbook naming who declares an incident, who runs the restore, and how you communicate with customers while you do.
| Recovery question | Weak answer | Strong answer |
|---|---|---|
| What do you back up? | Just the main table | All entities, files, and schema config |
| How often? | "When I remember" | Automated daily or weekly cron |
| Where does it live? | Inside Base44 | Storage you own, ideally two locations |
| Does restore work? | Never tested | Verified by periodic test restores |
| Who acts in an incident? | Nobody knows | A one-page runbook with named owners |
You do not need all five perfected on day one. The highest-leverage move is the automated export to storage you own, because it eliminates the worst outcome, which is a destructive event with no copy to restore from. The runbook and the test restores turn a backup into genuine resilience, and they are quick to add once the export exists. A recoverable copy belongs on the same checklist as the other things you confirm before a real launch, which we lay out in is my Base44 app ready to launch. If you are also weighing whether your app should leave the platform entirely, that is a separate decision from data safety, and our vendor lock-in deep dive and the Next.js and Supabase migration playbook walk through it without conflating it with the backup question. For apps handling sensitive records, our Base44 security hardening checklist pairs naturally with a recovery plan.
Order a $497 Data-Safety Audit for Peace of Mind
If the honest answer to "is my data safe?" is "I'm not sure," that uncertainty is the problem worth solving this month, not next quarter. A $497 production audit from our team maps exactly where your data lives, checks which of Base44's own recovery tools your plan actually includes, grades your current backup posture against the five recovery questions, identifies the specific gaps that would hurt you in an incident, and hands you a concrete export and disaster-recovery plan you can act on. The $497 fee is credited in full against any fix, build, migration or written-recommendation engagement booked within 30 days, so the diagnosis effectively pays for itself when it leads to a fix-sprint engagement. You can book the data-safety audit directly and have clarity within days rather than discovering your gaps the hard way during the next outage. For founders with real customer data, it is the cheapest insurance available against a single unrecoverable loss, and the calm of knowing is worth more than the fee.
Related reading
- Data loss when returning to a Base44 app — how saved records vanish when users come back to a live app, and how we recover them.
- No SLA below Enterprise and the outage risk it creates — why platform support is not a recovery plan and what to do instead.
- Base44 vendor lock-in deep dive — what is portable, what is locked, and the real cost of leaving.
- Base44 to Next.js and Supabase migration playbook — the step-by-step path if you decide to hold your own data permanently.
- Base44 security hardening checklist — the safety controls that belong alongside a backup routine.
- Is my Base44 app secure? — how data safety fits into the broader security picture for a live app.