[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fQsu4F7jpV9T68cwMvTzxVX3eEVXdFzmDGObq668ZyfA":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":25,"hasDownload":26,"fileName":27,"youtubeId":28,"domainCrumb":29,"clusterCrumb":32},"381","8A3DE525-5132-F546-87C8-1DC50B8B9620","E46BDB0A-2979-1E40-93F7-AC40185848A5","B11BED08-2F4E-4C45-9373-6175FA721411","article","how-to-manage-container-data-in-filemaker","How to manage container data in FileMaker","A practical guide to storing PDFs, photos and files in FileMaker without wrecking backup speed or database performance.","Your FileMaker file used to open in two seconds. Now it takes ten, backups run overnight instead of in twenty minutes, and every technician who syncs the mobile app over 4G complains about timeouts. Nine times out of ten, when we get called in to look at a sluggish FileMaker system, container fields holding photos, PDFs and scanned documents are a big part of the story.\n\nThis article walks through exactly how container data should be stored, why the default settings quietly cause problems, and what a proper container strategy looks like once a system has real volume behind it.\n\n## What is a container field, really?\n\nA container field is FileMaker's way of storing a file — an image, PDF, Word document, audio clip, or even a signature capture — as part of a record, the same way a text field stores a name. That's exactly what makes it so easy to misuse. A developer adds a container field to a \"work order\" table, users start attaching site photos, and within a year that one field holds gigabytes of binary data sitting right next to the transactional data everyone queries all day.\n\nUnlike a text or number field, a container field's content isn't small. A single delivery photo can be 3-5 MB. A signed contract PDF might be 500 KB. Multiply that by thousands of records a year, and the container data quickly dwarfs the actual business data.\n\n## Why does storing files inside FileMaker slow everything down?\n\nBy default, FileMaker gives you two storage options for a container field, and the choice matters enormously:\n\n1. **Store data in this field** (embedded) — the file's binary data is written directly inside the .fmp12 file, mixed in with every other record.\n2. **Store only a reference to the file** — FileMaker keeps a pointer to a file sitting elsewhere (a folder, a server volume), and the database itself stays lean.\n3. **Use secure storage (external, managed by FileMaker Server)** — files live outside the .fmp12 file but are still fully managed, encrypted, and backed up by FileMaker Server, with FileMaker handling all the referencing automatically.\n\nHere's the concrete problem we see constantly: a company set up their solution years ago with embedded container fields for scanned invoices. Every invoice, every year, added a few hundred KB directly into the main database file. After five years, the .fmp12 file balloons to 40+ GB. Now:\n\n- Nightly backups take hours instead of minutes, because FileMaker Server has to copy the entire file, photos and all, every single time.\n- Opening the file over a WAN connection is painfully slow, because container data travels with every sync.\n- A single corrupted record recovery becomes a nightmare, because the whole file — not just the business data — has to be rebuilt or restored.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F197?w=700&f=webp\" alt=\"database file bloated by embedded photos versus lean file with external storage folder\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## How should you actually store container data in FileMaker?\n\nAs a rule of thumb: **use FileMaker Server's managed external (secure) storage for anything beyond a handful of small files.** This is the setting that gives you the best of both worlds — the file physically lives outside the main database on the server's disk, but from the user's point of view it behaves exactly like a normal container field: click, and the photo or PDF opens.\n\nA practical decision guide:\n\n- **Small, static files, low volume (a company logo, a handful of signature images)** — embedded storage is fine. No real downside if the total volume stays under a few hundred MB.\n- **Growing volume of documents or photos tied to daily transactions (delivery photos, scanned invoices, inspection reports)** — always use managed external storage. This is the single biggest performance lever available and it takes minutes to set up correctly from day one.\n- **Very large media (drone footage, CAD drawings, video walkthroughs)** — consider storing the file in a dedicated document management system or cloud storage (SharePoint, S3, Azure Blob) and keeping only a link or reference field in FileMaker. FileMaker becomes the index and workflow layer, not the file server.\n\n## What if the container fields were already set up wrong?\n\nThis is the situation we run into most: a solution built years ago, container fields set to embedded storage, and now the file is enormous. The good news is this is fixable without a rebuild.\n\n1. **Measure first.** Use the Database Design Report or a script that sums container field sizes to find out how much of the file's bulk is actually container data versus business data.\n2. **Add a new container field with external secure storage**, and script a one-time migration that copies every existing file from the old embedded field into the new one, record by record.\n3. **Run FileMaker Server's file maintenance \u002F save-a-copy (compacted) process** afterward — simply switching storage type doesn't shrink the file until it's compacted.\n4. **Retire the old field** once every record has migrated and been verified, rather than deleting it immediately — this gives you a rollback path if something was missed.\n5. **Re-baseline your backup and sync times** after migration, so you have a documented before\u002Fafter to justify the effort to stakeholders.\n\nThis kind of cleanup is exactly the type of structural work covered in our broader guide on [how to improve the performance and structure of a FileMaker solution](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution) — container storage is rarely the only issue, but it's often the fastest win.\n\n## Does container storage affect mobile and web users differently?\n\nYes, and this catches teams off guard. A field technician using FileMaker Go on a job site, or an office worker accessing a FileMaker WebDirect layout, is often on a slower or metered connection than someone on the office LAN. If container fields are embedded, every layout that shows a photo forces the full file to download before the layout even finishes rendering — even if the user never intends to open it.\n\nWith external secure storage, FileMaker can be smarter about this: thumbnails and previews load quickly, and the full-resolution file is only pulled down when the user actually clicks to open it. If your team supports field workers on FileMaker Go, this alone can be the difference between a form that opens instantly and one that visibly hangs every time a photo field comes into view.\n\n## Should you connect container fields to AI or document tools?\n\nOnce container data is well structured, it becomes genuinely useful for automation — not just storage. A common example: a delivery photo or scanned invoice sitting in a container field can be run through an OCR or AI vision step to automatically extract a PO number, VAT amount, or delivery status, rather than having someone type it in by hand after the fact. This is one of the more practical uses of adding AI tooling inside FileMaker — the container field becomes the input to a workflow, not just an archive.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F196?w=700&f=webp\" alt=\"scanned document flowing from container field into AI extraction into database fields\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## What's a sensible container field checklist before you go live?\n\n- [ ] Decide storage type (embedded vs. external secure) per field, based on expected volume — not by default.\n- [ ] Confirm FileMaker Server is configured to host external container storage on adequate, monitored disk space.\n- [ ] Set a naming\u002Ffolder convention for external containers so IT can locate files outside FileMaker if ever needed.\n- [ ] Build in file-type and size validation on upload, so a 200 MB video doesn't land in a field meant for photos.\n- [ ] Include container storage in your backup and disaster-recovery plan — external files still need to be backed up, just separately from the .fmp12 file.\n- [ ] Re-check container field sizes annually as volume grows — what was fine at 10,000 records may not be fine at 500,000.\n\n## FAQ\n\n**Does changing container storage type risk losing existing files?**\nNot if done correctly — always migrate via script into a new field and verify counts\u002Fchecksums before removing the old one. Never simply flip the storage type on a field that already contains embedded data expecting it to convert automatically.\n\n**Can container fields be encrypted?**\nYes — FileMaker Server's secure storage encrypts container data at rest, which also matters for compliance if you're storing scanned ID documents, contracts, or medical files.\n\n**Will external storage break existing scripts or layouts?**\nNo. From the layout and script perspective, a container field behaves the same regardless of storage type — the difference is entirely in where and how FileMaker physically stores the bytes.\n\n**Is there a hard file-size limit for container fields?**\nFileMaker itself supports very large files, but practically, keep individual files under a few hundred MB — beyond that, a proper document management or cloud storage system is almost always the better home for the file.\n\nGetting container storage right is rarely a one-time decision — it's something that needs revisiting as a FileMaker solution grows from a handful of users into a system the whole company depends on. If your database has started to feel heavy, your backups are creeping longer, or you're wondering whether your container fields should be feeding into an AI-based document workflow instead of just sitting there, Loggix can review the structure with you and map out a practical next step — whether that's a storage migration, a tighter FileMaker Server setup, or connecting your document data to the other systems your business runs on.","\u003Cp>Your FileMaker file used to open in two seconds. Now it takes ten, backups run overnight instead of in twenty minutes, and every technician who syncs the mobile app over 4G complains about timeouts. Nine times out of ten, when we get called in to look at a sluggish FileMaker system, container fields holding photos, PDFs and scanned documents are a big part of the story.\u003C\u002Fp>\n\u003Cp>This article walks through exactly how container data should be stored, why the default settings quietly cause problems, and what a proper container strategy looks like once a system has real volume behind it.\u003C\u002Fp>\n\u003Ch2>What is a container field, really?\u003C\u002Fh2>\n\u003Cp>A container field is FileMaker's way of storing a file — an image, PDF, Word document, audio clip, or even a signature capture — as part of a record, the same way a text field stores a name. That's exactly what makes it so easy to misuse. A developer adds a container field to a "work order" table, users start attaching site photos, and within a year that one field holds gigabytes of binary data sitting right next to the transactional data everyone queries all day.\u003C\u002Fp>\n\u003Cp>Unlike a text or number field, a container field's content isn't small. A single delivery photo can be 3-5 MB. A signed contract PDF might be 500 KB. Multiply that by thousands of records a year, and the container data quickly dwarfs the actual business data.\u003C\u002Fp>\n\u003Ch2>Why does storing files inside FileMaker slow everything down?\u003C\u002Fh2>\n\u003Cp>By default, FileMaker gives you two storage options for a container field, and the choice matters enormously:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Store data in this field\u003C\u002Fstrong> (embedded) — the file's binary data is written directly inside the .fmp12 file, mixed in with every other record.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Store only a reference to the file\u003C\u002Fstrong> — FileMaker keeps a pointer to a file sitting elsewhere (a folder, a server volume), and the database itself stays lean.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Use secure storage (external, managed by FileMaker Server)\u003C\u002Fstrong> — files live outside the .fmp12 file but are still fully managed, encrypted, and backed up by FileMaker Server, with FileMaker handling all the referencing automatically.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Here's the concrete problem we see constantly: a company set up their solution years ago with embedded container fields for scanned invoices. Every invoice, every year, added a few hundred KB directly into the main database file. After five years, the .fmp12 file balloons to 40+ GB. Now:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Nightly backups take hours instead of minutes, because FileMaker Server has to copy the entire file, photos and all, every single time.\u003C\u002Fli>\n\u003Cli>Opening the file over a WAN connection is painfully slow, because container data travels with every sync.\u003C\u002Fli>\n\u003Cli>A single corrupted record recovery becomes a nightmare, because the whole file — not just the business data — has to be rebuilt or restored.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F197?w=700&f=webp\" alt=\"database file bloated by embedded photos versus lean file with external storage folder\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>How should you actually store container data in FileMaker?\u003C\u002Fh2>\n\u003Cp>As a rule of thumb: \u003Cstrong>use FileMaker Server's managed external (secure) storage for anything beyond a handful of small files.\u003C\u002Fstrong> This is the setting that gives you the best of both worlds — the file physically lives outside the main database on the server's disk, but from the user's point of view it behaves exactly like a normal container field: click, and the photo or PDF opens.\u003C\u002Fp>\n\u003Cp>A practical decision guide:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Small, static files, low volume (a company logo, a handful of signature images)\u003C\u002Fstrong> — embedded storage is fine. No real downside if the total volume stays under a few hundred MB.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Growing volume of documents or photos tied to daily transactions (delivery photos, scanned invoices, inspection reports)\u003C\u002Fstrong> — always use managed external storage. This is the single biggest performance lever available and it takes minutes to set up correctly from day one.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Very large media (drone footage, CAD drawings, video walkthroughs)\u003C\u002Fstrong> — consider storing the file in a dedicated document management system or cloud storage (SharePoint, S3, Azure Blob) and keeping only a link or reference field in FileMaker. FileMaker becomes the index and workflow layer, not the file server.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>What if the container fields were already set up wrong?\u003C\u002Fh2>\n\u003Cp>This is the situation we run into most: a solution built years ago, container fields set to embedded storage, and now the file is enormous. The good news is this is fixable without a rebuild.\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Measure first.\u003C\u002Fstrong> Use the Database Design Report or a script that sums container field sizes to find out how much of the file's bulk is actually container data versus business data.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Add a new container field with external secure storage\u003C\u002Fstrong>, and script a one-time migration that copies every existing file from the old embedded field into the new one, record by record.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Run FileMaker Server's file maintenance \u002F save-a-copy (compacted) process\u003C\u002Fstrong> afterward — simply switching storage type doesn't shrink the file until it's compacted.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Retire the old field\u003C\u002Fstrong> once every record has migrated and been verified, rather than deleting it immediately — this gives you a rollback path if something was missed.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Re-baseline your backup and sync times\u003C\u002Fstrong> after migration, so you have a documented before\u002Fafter to justify the effort to stakeholders.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>This kind of cleanup is exactly the type of structural work covered in our broader guide on \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution\">how to improve the performance and structure of a FileMaker solution\u003C\u002Fa> — container storage is rarely the only issue, but it's often the fastest win.\u003C\u002Fp>\n\u003Ch2>Does container storage affect mobile and web users differently?\u003C\u002Fh2>\n\u003Cp>Yes, and this catches teams off guard. A field technician using FileMaker Go on a job site, or an office worker accessing a FileMaker WebDirect layout, is often on a slower or metered connection than someone on the office LAN. If container fields are embedded, every layout that shows a photo forces the full file to download before the layout even finishes rendering — even if the user never intends to open it.\u003C\u002Fp>\n\u003Cp>With external secure storage, FileMaker can be smarter about this: thumbnails and previews load quickly, and the full-resolution file is only pulled down when the user actually clicks to open it. If your team supports field workers on FileMaker Go, this alone can be the difference between a form that opens instantly and one that visibly hangs every time a photo field comes into view.\u003C\u002Fp>\n\u003Ch2>Should you connect container fields to AI or document tools?\u003C\u002Fh2>\n\u003Cp>Once container data is well structured, it becomes genuinely useful for automation — not just storage. A common example: a delivery photo or scanned invoice sitting in a container field can be run through an OCR or AI vision step to automatically extract a PO number, VAT amount, or delivery status, rather than having someone type it in by hand after the fact. This is one of the more practical uses of adding AI tooling inside FileMaker — the container field becomes the input to a workflow, not just an archive.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F196?w=700&f=webp\" alt=\"scanned document flowing from container field into AI extraction into database fields\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>What's a sensible container field checklist before you go live?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Decide storage type (embedded vs. external secure) per field, based on expected volume — not by default.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Confirm FileMaker Server is configured to host external container storage on adequate, monitored disk space.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Set a naming\u002Ffolder convention for external containers so IT can locate files outside FileMaker if ever needed.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Build in file-type and size validation on upload, so a 200 MB video doesn't land in a field meant for photos.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Include container storage in your backup and disaster-recovery plan — external files still need to be backed up, just separately from the .fmp12 file.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Re-check container field sizes annually as volume grows — what was fine at 10,000 records may not be fine at 500,000.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Does changing container storage type risk losing existing files?\u003C\u002Fstrong>\nNot if done correctly — always migrate via script into a new field and verify counts\u002Fchecksums before removing the old one. Never simply flip the storage type on a field that already contains embedded data expecting it to convert automatically.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can container fields be encrypted?\u003C\u002Fstrong>\nYes — FileMaker Server's secure storage encrypts container data at rest, which also matters for compliance if you're storing scanned ID documents, contracts, or medical files.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Will external storage break existing scripts or layouts?\u003C\u002Fstrong>\nNo. From the layout and script perspective, a container field behaves the same regardless of storage type — the difference is entirely in where and how FileMaker physically stores the bytes.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is there a hard file-size limit for container fields?\u003C\u002Fstrong>\nFileMaker itself supports very large files, but practically, keep individual files under a few hundred MB — beyond that, a proper document management or cloud storage system is almost always the better home for the file.\u003C\u002Fp>\n\u003Cp>Getting container storage right is rarely a one-time decision — it's something that needs revisiting as a FileMaker solution grows from a handful of users into a system the whole company depends on. If your database has started to feel heavy, your backups are creeping longer, or you're wondering whether your container fields should be feeding into an AI-based document workflow instead of just sitting there, Loggix can review the structure with you and map out a practical next step — whether that's a storage migration, a tighter FileMaker Server setup, or connecting your document data to the other systems your business runs on.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901677000,[19,20,21,22,23,24],"FileMaker container fields","FileMaker performance","database storage","FileMaker Server","document management","external container storage","\u002Fapi\u002Fknowledge\u002Fimage\u002F381\u002F?v=8245c482b976",false,"",null,{"title":30,"slug":31},"FileMaker and Claris","filemaker-and-claris",{"title":33,"slug":34},"How to improve the performance and structure of a FileMaker solution","how-to-improve-the-performance-and-structure-of-a-filemaker-solution"]