Your App's database

An App remembers things between visits by saving records into lists — sign-ups, orders, posts, the accounts of the people using it. Everything about that lives in the App editor's Develop › Data: one page with three containers, and settings that open from them as windows.

Where your App's data lives

Open Develop › Data and you see three containers:

• Records — a table of what your App has stored, one list at a time.
• Lists — a card per list: its name, who may open and write it, how many fields it has, what its links point at, and which of your other Apps it is shared with.
• Storage — whether your App saves at all (On or Off), and how much storage it uses.

Anything more than a value and its status opens as a window: a record, a list's settings, the storage settings, an import or export, and the SQL console.

Data applies once your App can go live — once it has a page, a backend or an action. Until then Data says Nothing to publish · add a page, a backend or an action. Records belong to the published App, so until you publish once the containers are empty and each control opens Publish first.

Turn on saving

Your App stores nothing until saving is on. Under Storage, press Settings and turn Saving on. Before you confirm, the step shows what you get — storage Shared across your apps, Live updates, Uploads, and Stop any time — and what it costs: free up to your account's allowance, which all of your Apps share, with a flat monthly price per block of storage only After that. Turning it on needs no payment method. Storage you buy is managed in Settings › Add Ons.

Turning saving off asks first: your Records are Kept, New saves are Stopped, and the App Stops loading its data. Turn it on again later and your records are still there.

When your Apps outgrow the free storage

Every account's Apps share 1 GB of free storage, and the limit is real: once a day MotherFluxer measures what all of your Apps have stored together. Storage shows that total against the limit.

• A little over is fine. Your Apps keep saving while they are up to a fifth past the limit.
• Further past it, new saves pause. Your published Apps keep working: visitors can still read every record you have, and nothing is deleted. Only new saves wait, and you get an email saying so.
• To resume saves, add storage in Settings › Add Ons, or delete records you no longer need. Saves start again at the next daily check that finds your Apps no more than a fifth past their limit.

With storage you have bought, the same rules apply at your plan's size — unless Auto-upgrade storage is on in Settings › Add Ons, which moves you up to the next size instead of pausing.

Nothing about a list or a record can be saved while saving is off. A list's or a record's window says Saving · Off at the top and offers no Save: the owner gets Turn on right there, and a collaborator is told it is The owner’s to change.

Browse and edit your records

Records shows one list at a time, from one dataset. Pick the list from the menu above the table — each list shows its record count — and then:

• Type in the Filter box in a column's heading to narrow that column.
• Use Search to search every record of the list, not just the page on screen.
• Press a column heading to sort by it; Added sorts by when each record was saved.
• Page through with Previous and Next; the count between them reads like "1–50 / 86".

The table shows each field under its label and each value in its format, with hidden fields masked. Press a record's pencil to open it in its window and change it, or the trash icon to delete it. Add record opens an empty record. Refresh reads the table again, and Settings opens what you can do to your Draft's data as a whole.

Live data and Draft data

Your App's data comes in two datasets:

• Live — what real visitors read and write on your published App.
• Draft — the working copy your Draft uses while you build, for you and the App's building assistant to try changes against. Nothing you do here reaches your visitors.

As the owner you pick which one Records shows with the Live / Draft choice at its top. A collaborator always works on the Draft — Live's records are your customers'.

The Draft's data starts as a full copy of Live the first time your Draft gets a dataset of its own. Until then Settings on Records says None yet · the Draft uses Live’s records, and Draft can't be picked.

A change to the Draft's data lands at once; deleting a record from the table asks first, since there is no undo. A change to Live is checked before anything is written and held as a confirmation — Change live data or Delete live data — that names the List, how many Records it touches, that a Backup is Taken first, and Large change when it is one. Only Apply (or Delete) writes it.

Copy Live into the Draft, or empty it

Your Draft's data doesn't follow Live on its own, and publishing never touches it — it stays as you left it. Under Records, press Settings to reach Draft data:

• Copy live → Copy (owner only) replaces your Draft's records with a fresh copy of Live. Before it runs, Copy Live into the Draft says what happens: Draft records are Replaced, Live records are Untouched, Your list changes are Applied again on top, Lists only in the Draft are Untouched, and Hidden fields are Blanked. Afterwards it says how many records it copied.
• Empty deletes every one of the Draft's records and keeps your lists. Live's records are untouched.

Both ask first, and neither ever changes Live.

Import and export records

Export saves the list on screen, from the dataset on screen, as CSV or JSON — press Download. Import adds a .csv or .json file to the list on screen, in the dataset on screen, each row as a new record — press Choose file, then Import. Each window names the List and the dataset it reads From or writes Into, so you always see which data you are touching; neither ever defaults to Live.

An import is checked first against the list's rules, and a file that would break one is refused whole rather than half-loaded. Into Live, it is held as the same Change live data confirmation, with a backup taken first. A collaborator imports into and exports from the Draft's data.

Who each list's records belong to

Each list decides this for itself. Under Lists, press a list's settings icon, and in its Access section choose Belongs to:

• Everyone — everyone shares one set of records, and records carry no owner.
• Each device — records carry no owner either, but a visitor only ever reads the records their own browser added.
• Each signed-in user — every record is stamped with the signed-in visitor who added it, and an anonymous save is refused. This needs sign-in turned on in Manage › Users; until it is, the choice can't be picked and the window says where to turn it on.

Setting this per list is what lets one App hold a shared catalogue everyone reads beside a private list only its author sees. An existing list saves its access on its own with Save access; a change that would strand records already stored is refused, and the window says why.

"Each device" is a convenience, not a privacy wall. It separates records so each browser sees its own, but a visitor is identified only by the browser or device they're on, never by a confirmed identity. Do not use it for anything private or sensitive. For records that must be genuinely private to one person, turn on sign-in and use Each signed-in user, which MotherFluxer enforces on its own servers.

Who can read and change each list's records

Written by, under Access, decides who can add and change a list's records from a page:

• This app's actions — the choice a new list starts on. No page can write to it, signed in or not; only your App's actions, schedules and webhooks can. Use it whenever an action enforces a rule, because nobody can skip the rule by writing to the list directly.
• Signed-in people — anyone with an account on your App. This needs sign-in turned on in Manage › Users.
• Anyone — anyone on the internet, signed in or not. A list that belongs to Each signed-in user can't choose it, because each record needs an author.

Choosing a wider one asks first: Let a page write this list? says who you are letting in and, for a list only your actions could write, that a rule an action enforces can now be skipped. Open it confirms it.

A list that belongs to Each signed-in user also offers Opens for:

• Private — each person reads only their own records.
• Public read — anyone reads every record. Good for comments and reviews.

The Means line spells out what these settings do together, such as Anyone reads every row, Each device reads only its own rows, Each edits only their own or Only this app's actions write. Treat a list that says Anyone edits any row as public to your App's audience. The list's card sums it up in one word: Open to all, Per device, Private, Public read or This app's actions.

These rules are enforced on MotherFluxer's servers, not in the page, so they hold even for someone calling your App's data directly. Choosing the right settings for what you store is your responsibility as the builder.

Lists your other Apps read

A list in one of your Apps can be shared with another of your Apps as a data link, which you set up in that other App's Equip › Connect or in Settings › Account › Connections & Keys. The records never move: the other App's actions read the list — or read and write it, if you linked it that way — right where it is, under the list's own rules, Draft against Draft and Live against Live.

On the App that holds the list, Develop › Data shows it on the list's card under Lists: Shared with and the name of each App that reads it, then how far the link reaches — for example "Shared with Shop · Read and write". Only you, the owner, see this line; it names your other Apps, so a collaborator's cards don't show it.

A list that holds people's details can only be shared for reading. To stop sharing a list, revoke the other App's access in Connections & Keys; that App's actions are then told the list is no longer linked.

A posted App's or a co-op's data

An App posted to Slop runs as its own frozen copy, and the data its visitors save collects on that copy — never in your own Live App. A co-op's App keeps its own data in the same way. When you open one of these Apps, its Data sits on its one Manage tab, and it is read and exported only:

• Records opens on Live: you can filter, search, sort, page through and Export the records, but not add, edit, delete or import them, and there is no SQL console.
• Lists shows each list's card and its query builder, with no new list and no list settings.
• Storage says whether the App saves, with no settings — it can't be changed here.

When a list change reaches your App

The Lists container says when a change to a list lands:

• On publish — your Draft keeps its own data, so the change applies to the Draft's data now and reaches Live the next time you publish.
• Live at once — your App still works on one dataset, so the change applies to Live as soon as you save it.

A list's window says the same above its fields, before you save.

Publish changes to your live data without downtime

When you change a list's shape — rename a field, add a new one — and publish, MotherFluxer updates your Live data to the new shape automatically, with no downtime. Your App keeps serving visitors the whole time, and no field ever goes blank while the change rolls out. You never have to take your App offline or migrate anything by hand.

Renaming a field keeps the values that were in it — they move to the new name, record by record. If a record already holds a value under the new name, that value wins and the rename leaves it alone: a rename never overwrites data you already have. When a change adds a field and says what existing records should hold, that value is written into the records that don't have one and skips the ones that do. Records are updated in place, so links between your lists keep pointing at the same records.

Your records change over in batches, and the new shape becomes the one your App reads only once the last record has been rewritten — so a visitor never sees a half-renamed list. A backup of Live is taken first, and before publishing a change that could affect records already in your Live App, the editor shows you exactly what will change and asks you to confirm.

Hide sensitive fields from your Draft's data

Because your Draft's data starts as a copy of your real Live data, it can contain real personal information — and that copy is what you and the App's building assistant work against. You can keep chosen fields out of it.

In a list's window, press the field's settings icon, select More settings, and turn on the switch on its Hide the value line. That field is blanked whenever Live's records are copied into the Draft, so its real values never appear in the working copy, and the editor masks it wherever it shows your records — the table, and a record's window until you press Show. This is off by default: nothing is hidden unless you choose it.

Hiding takes effect the next time Live is copied into the Draft — when your Draft first gets its own data, or when you use Copy live — not on records already copied. It only affects the Draft's copy; your Live data is never changed by it.

Run SQL against your App's data

As the owner, press Query on Records to open the SQL console. It Reads and writes your App's own tables, and also offers mf_data · read-only view of the records your lists save. Type a statement and press ⌘/Ctrl + Enter or Run; results come back in a table below, with the row count. The console runs against your Live data, on whichever database backs your App — the shared one or a private one. A very large answer is cut short and says · capped — narrow the query for more.

Running SQL can incur cost, so it needs a verified payment method on the owner's account. Until then the console says Needs a verified card · Settings and Run stays off. The console is absent for collaborators.

Connect an outside SQL client

Once saving is on and your App has Live data, the owner's Storage settings include a Connection section for connecting a SQL client of your own to your App's Live data: the Host, the Database, the User and the Connection string, which you can copy.

The password is Shown once and Never stored. Press New password to make one — it asks first, because the Old password Stops working — then copy the new one straight away. Limits lists how many connections you may hold and how long a statement may run. Like the console, a direct connection needs a verified payment method. Collaborators don't see this section.

Move your App onto a private database

By default your App shares one database with your other Apps. As the owner, you can move it onto a database of its own from Storage → Settings → Private database: it Gives an Own database, Full SQL, Extensions and a Private connection. Press Upgrade to open the move.

Before you start, the move window shows exactly what will happen, measured from your App's real data: how many records and lists it carries, anything you made with SQL yourself that stays behind, whether your direct connection string stops working, what happens to the database you are leaving, and what your bill becomes — a flat monthly fee plus usage at cost, with one fee covering every App you move across. If the move can't happen — no payment method on file, say — it says so under Not possible right now instead of letting you start it.

The move takes a few minutes. During it, Pages keep serving, Saves refused until the switch, and the Copy checked before the switch — your App changes over only after every record has been copied and counted. Meanwhile Move, in the Storage settings, shows the step it is on — from Pausing new data and Copying to Checking and Switching — and a move that fails says Failed · the app is unharmed.

On a private database, When idle chooses Rest (close to nothing while idle, and it Wakes in 1–3 s) or Awake (No wake delay, Paid while idle), and Price shows what it costs. An unpublished App says Publish again first instead of offering Upgrade.

Screens that update themselves on a private database

One difference is worth knowing before you move: screens that update themselves the moment your data changes work on the shared database only. On a private database, a page shows the data it loaded and refreshes when your App asks it to, rather than the instant a record changes. Live chat, typing indicators and who's-here are unaffected — they work the same on both. The move window says this too, so you see it before you confirm.

Moving back, and changing your mind

To leave a private database, press Move back in Storage → Settings → Private database. The window measures the move first, just like moving up. Your records are copied back and checked before your App switches over — nothing is thrown away.

What happens to the private database you leave depends on your account, and the window tells you which before you start:

• It is kept for a while — typically when this was your only App on a private database, until the end of the month you already paid for, at no extra cost. Storage then shows it under Previous as Kept until a date, with No extra cost, and Upgrade again takes your App straight back to it. To end that window early, press the trash icon beside it; it deletes the kept database for good, so it asks you to type DELETE MY DATA first.
• It is deleted when the move finishes — typically when another of your Apps still has a private database, so there is no already-paid window to keep it inside. The window asks you to type DELETE MY DATA before you can start.

Turning saving off does the same move first, so your records land back in the shared database rather than disappearing with the private one — turn saving on again later and they're still there. Taking your App off the web does too: unpublishing keeps every record, and a private database's records are carried back so its monthly charge stops. Deleting the App itself is the only thing that destroys its data.

If your payment method goes away

Paid upgrades — Background power and a Private database — need a payment method on file. If yours is removed, MotherFluxer does not pause your App and does not delete anything: it keeps serving your pages and moves the upgrades back to the free plan. Your records are carried back to the shared database and checked, exactly as a move you asked for; the old database is kept for the window you already paid for; background power is switched off and your App keeps serving its pages.

On Manage › Publish, the Live card's settings show it under Plan: Lapsed, the upgrades that came off, and No payment method. Add a payment method (Add card), then press Restore, and MotherFluxer puts back exactly what came off — the same background power, and a move back onto the same kept database with your records intact.