Most useful apps hold more than text. A client portal collects signed documents, a listing app shows photos, and a training app plays short videos. Overskill keeps those files in one place and your app's records in another, and the record points to its file with a link.
This guide explains where each part lives, why the builder works this way, and what to ask for when it says it cannot store something the way you described. You do not need to change anything to follow it. It describes how the builder already sets up your app.
Where your files and records live
Your app has two kinds of storage.
- Records are the rows your app saves: a booking, a client, a product, a lesson. Each record has fields such as a name, a date, a price and a status.
- File storage holds the files themselves: photos, videos, audio, PDFs and anything else someone uploads.
When a record needs a file, the builder adds an upload to your app. The file goes into file storage, and the record keeps a link to it in a field with a name like photo_url or document_url. When the page shows the record, it uses that link to display the photo or play the video.
The same applies to images you add yourself, such as a logo or a header picture. They are saved as files, not written into a record.
Why files stay out of your records
A single record can hold only a limited amount of data. That is plenty for names, dates, notes and prices, but a single phone photo can be several megabytes and a short video much more. A file stored inside a record can fill that space at once. The upload then fails, or the app slows down for every visitor who loads that list.
Keeping the two apart has other benefits:
- Pages stay fast. A list of 200 products loads 200 small records, and each photo comes from file storage instead of weighing down the list.
- Your data stays easy to move. Records stay small enough to export, back up and copy into another tool.
- Files are delivered efficiently. File storage is designed for sending large files to visitors.
When the builder says it can't store something
The builder will not create a field meant to hold a file, and it will not save a picture or a very large value inside a record. You may notice this in three ways:
- You asked for a field called
photo, and the builder usually creates something likephoto_urlwith an upload instead. - You pasted a picture, or a long block of text that a copied picture turns into, and the builder said it cannot save it as a value.
- You asked it to store a very long document or list in one field, and it said the value is too large.
In each case, describe the result you want rather than the field. For a picture or file, ask the builder to let people upload it and to save its link with the record. For a long document, ask it to split the content into smaller records, such as one per chapter or section, or to keep the document as a file.
This check applies to every app, and it cannot be switched off for one app. Fields and records you already have are not changed.
Frequently asked questions
Will this change my existing app? No. The builder applies this check only when it sets up a new field or saves a new value. It does not rewrite tables you already have.
My app already keeps pictures inside its records. What should I do? Ask the builder to store new uploads as files and save their links. If your app shows an error that a value or record is too large, or you were told its database move is on hold, contact support with the app's name so our team can check the records you already have.
Why did the builder rename my field? A name like photo_url says that the field holds a link, not the file itself. Your app still shows the photo.
I think the builder refused something it should have allowed. Contact support with the app's name and the message you sent to the builder. A link field (a name ending in _url, _key or _id, other than one ending in data_url, which names a file) or a short plain value should not be refused.