[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fOm24n1KTrATJgc_wiLyn1G0vBqKNuOzkHCdxCesM9V4":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":26,"hasDownload":27,"fileName":28,"youtubeId":29,"domainCrumb":30,"clusterCrumb":33},"376","613ED838-04B9-4447-89EB-3E317D9A29BD","E46BDB0A-2979-1E40-93F7-AC40185848A5","B11BED08-2F4E-4C45-9373-6175FA721411","article","how-to-optimize-filemaker-searches-and-sorts","How to optimize FileMaker searches and sorts","Why FileMaker searches and sorts slow down as data grows, and the concrete steps to make them fast again — indexing, scripting, layout and hosting fixes.","You click Find, type in a customer number, and then you wait. Three seconds. Five seconds. Ten, if someone else on the network is running a report at the same time. A sort on 40,000 invoice records used to be instant when the database was new — now your team quietly avoids sorting by date because it \"locks up the screen\" for a minute. Nobody redesigned anything on purpose; the system just grew, and the searches and sorts that felt fine at 5,000 records are painful at 500,000.\n\nThis article walks through exactly why that happens in FileMaker and Claris solutions, and the concrete fixes — from indexing and scripted finds to layout and hosting choices — that bring speed back without a rebuild.\n\n## Why do FileMaker searches get slower as the database grows?\n\nA Find request in FileMaker either uses an **index** or it doesn't. When it does, FileMaker looks up matching values in a pre-built list — fast, regardless of table size. When it doesn't, FileMaker has to open every single record and check the field value one by one. That's called an **unstored (unindexed) find**, and it scales badly on purpose: 5,000 records might take a blink, 500,000 records can take minutes.\n\nThe most common causes we see in real client solutions:\n\n- **Calculation fields used in Find requests.** A calculation field is only indexed if every field it references is itself indexable and stored. Reference a global field, an unstored calc, or a related field, and FileMaker can't index it — every search on it becomes a full table scan.\n- **Container fields being searched by content.** Searching inside PDFs or images stored in containers is inherently slow unless full-text indexing is explicitly enabled for that field.\n- **Fields marked \"do not store\" for calculation results**, often set that way years ago to save disk space when storage was expensive — a trade-off that made sense in 2008 and now silently taxes every search.\n- **Related (portal) fields used directly as a Find criterion** across a relationship instead of a proper indexed match field.\n- **Text fields with a huge unique value count** (like free-text notes) combined with wildcard searches (`*keyword*`), which can't use the index efficiently because the match could start anywhere in the string.\n\n## Why do sorts feel slower than searches on the same table?\n\nSorting has a different cost profile. FileMaker can sort quickly on indexed fields, but a sort on a calculation field, a summary field, or a field across a relationship forces FileMaker to compute or fetch a value for *every record in the found set* before it can order them. On a found set of 500 records that's invisible. On a found set of 100,000 records pulled in for a year-end report, that's the multi-minute freeze your finance team complains about every quarter.\n\nAnother frequent culprit: sorting by a field that lives in a **related table** through a one-to-many relationship. FileMaker has to resolve the relationship for each record before it can sort — this is dramatically slower than sorting on a field that lives directly in the table being displayed.\n\n## How do you actually fix slow searches? A step-by-step approach\n\n1. **Turn on storage\u002Findexing for fields that need it.** In Manage Database, open the field's storage options and set indexing to \"All\" for fields regularly used in Find requests. Do this selectively — indexing every field bloats the file and slows down data entry, since every write now has to update multiple indexes.\n2. **Replace unstored calculations with stored ones where possible.** If a calculation only references fields in the same record and doesn't use `Get()` functions that change per user\u002Fsession (like `Get(CurrentDate)`), it can usually be made stored — which makes it indexable.\n3. **Add a dedicated, indexed \"search key\" field** for cases where users need to search across multiple concatenated fields (e.g. name + city + postcode). Populate it via an auto-enter or trigger, and search that single field instead of forcing FileMaker to combine several unindexed lookups at Find time.\n4. **Script your Finds instead of relying on manual Find mode.** A scripted `Perform Find` with a precise, pre-built find request avoids the overhead of the user typing loose criteria, retrying, and re-searching. It also lets you constrain the found set in stages — find broadly first, then constrain — which is often faster than one large complex request.\n5. **Avoid wildcard searches on huge free-text fields where you can.** If users constantly search notes fields with `*word*`, consider a separate indexed keyword\u002Ftag field populated at data-entry time instead.\n6. **Check container field settings.** If full-text search inside PDFs isn't actually needed, turn it off — it adds real overhead to every import and edit.\n7. **Re-index after bulk imports.** Large data imports can leave indexes in a state where FileMaker rebuilds them on the next relevant search — schedule bulk imports for off-hours, or force a rebuild afterward.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F290?w=700&f=webp\" alt=\"magnifying glass over database records, one path marked indexed fast, one marked unindexed slow\" 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 do you fix slow sorts specifically?\n\n- **Sort on stored fields, not calculations**, wherever the business logic allows it.\n- **Pre-sort at the layout or script level** by choosing a sort order once and caching the found set, rather than re-sorting the same records repeatedly inside a loop.\n- **Avoid sorting across relationships.** If reports consistently need to be sorted by a related field (e.g. sort invoices by customer region), consider storing a copy of that value directly on the invoice record via a script trigger when the customer is assigned — a small denormalization that pays for itself in report speed.\n- **Limit the found set before sorting**, not after. Sorting 500 filtered records is always cheaper than sorting 100,000 and then filtering.\n- **Use summary fields carefully.** They're powerful for subtotals but can slow sorts and layout loads on very large found sets — test with production-sized data, not your 200-record development copy.\n\n## Does hosting and network setup affect search\u002Fsort speed too?\n\nYes — and it's often the real bottleneck, not the schema. A few things worth checking:\n\n- **FileMaker Server vs. peer-to-peer hosting.** Searches and sorts should always be evaluated server-side when the file is properly hosted; peer-to-peer sharing (one user's computer hosting the file for others) pushes far more raw data across the network and makes even indexed searches feel sluggish.\n- **WAN vs. LAN access.** Remote users connecting over a slow or high-latency internet connection will feel every unnecessary field on a layout, every unindexed search, and every large sort far more acutely than someone on the office LAN. This is exactly the kind of structural issue 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).\n- **Layout complexity.** A layout with dozens of unused fields, portals, and conditional formatting rules re-evaluates all of that for every record in a sort or found set, even if the user never scrolls to see it. Trim layouts used for searching and reporting to only what's needed.\n- **Server hardware and load.** A FileMaker Server under-provisioned in RAM will page cached data in and out constantly during large sorts — monitor server-side statistics (available in FileMaker Server Admin Console) during peak hours to see if this is happening.\n\n## A quick diagnostic checklist\n\nBefore touching schema, run through this list on the specific find\u002Fsort your users complain about:\n\n- [ ] Is the field being searched actually indexed (\"All\" in storage options)?\n- [ ] Is it a calculation field, and if so, is it stored or unstored?\n- [ ] Does the search or sort cross a relationship?\n- [ ] Is the layout used for this search overloaded with unused fields\u002Fportals?\n- [ ] Is the file properly hosted on FileMaker Server, not peer-to-peer?\n- [ ] Is the found set constrained *before* the sort runs, not after?\n- [ ] Has this been tested against production-scale data, not a small dev copy?\n\n## FAQ: FileMaker search and sort performance\n\n**Does adding more indexes always make searches faster?**\nNo. Every indexed field adds a small write cost on every create\u002Fedit\u002Fimport, so indexing fields that are rarely searched just slows down data entry for no benefit. Index deliberately, based on what users actually search.\n\n**Can AI or scripting help beyond manual optimization?**\nYes — increasingly, teams add lightweight AI-assisted search layers (for example, natural-language lookups powered by a connected AI tool) on top of a well-indexed FileMaker schema to help staff find records without needing to know exact field names or wildcard syntax. This works well as an added layer, but it doesn't replace fixing the underlying indexing — a slow, unindexed table will still be slow under an AI front end.\n\n**Why is a Find fast in the dev copy but slow in production?**\nBecause found-set size and network conditions matter enormously. A find that's instant on 300 test records can be genuinely slow on 300,000 live records, especially over WAN. Always performance-test against realistic data volumes.\n\n**Is it worth rebuilding the schema just for search speed?**\nRarely as a first step. Most search\u002Fsort slowness is fixable through indexing, field storage settings, scripted finds, and hosting\u002Flayout cleanup — a full schema rebuild is usually only justified when the underlying data model itself has grown incoherent, not just slow.\n\nIf your team has quietly started avoiding certain searches or reports because \"it's just slow,\" that's usually a sign the underlying field structure, indexing, or hosting setup hasn't kept pace with how much the solution has grown — not that FileMaker itself has hit a ceiling. Loggix regularly audits existing FileMaker solutions to find exactly which fields, relationships, or layouts are causing the slowdown, and can implement the fix directly, extend the solution with a connected web or reporting layer, or add AI-assisted search where it genuinely helps — all without forcing a rebuild of a system that's otherwise working well.","\u003Cp>You click Find, type in a customer number, and then you wait. Three seconds. Five seconds. Ten, if someone else on the network is running a report at the same time. A sort on 40,000 invoice records used to be instant when the database was new — now your team quietly avoids sorting by date because it "locks up the screen" for a minute. Nobody redesigned anything on purpose; the system just grew, and the searches and sorts that felt fine at 5,000 records are painful at 500,000.\u003C\u002Fp>\n\u003Cp>This article walks through exactly why that happens in FileMaker and Claris solutions, and the concrete fixes — from indexing and scripted finds to layout and hosting choices — that bring speed back without a rebuild.\u003C\u002Fp>\n\u003Ch2>Why do FileMaker searches get slower as the database grows?\u003C\u002Fh2>\n\u003Cp>A Find request in FileMaker either uses an \u003Cstrong>index\u003C\u002Fstrong> or it doesn't. When it does, FileMaker looks up matching values in a pre-built list — fast, regardless of table size. When it doesn't, FileMaker has to open every single record and check the field value one by one. That's called an \u003Cstrong>unstored (unindexed) find\u003C\u002Fstrong>, and it scales badly on purpose: 5,000 records might take a blink, 500,000 records can take minutes.\u003C\u002Fp>\n\u003Cp>The most common causes we see in real client solutions:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Calculation fields used in Find requests.\u003C\u002Fstrong> A calculation field is only indexed if every field it references is itself indexable and stored. Reference a global field, an unstored calc, or a related field, and FileMaker can't index it — every search on it becomes a full table scan.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Container fields being searched by content.\u003C\u002Fstrong> Searching inside PDFs or images stored in containers is inherently slow unless full-text indexing is explicitly enabled for that field.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Fields marked "do not store" for calculation results\u003C\u002Fstrong>, often set that way years ago to save disk space when storage was expensive — a trade-off that made sense in 2008 and now silently taxes every search.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Related (portal) fields used directly as a Find criterion\u003C\u002Fstrong> across a relationship instead of a proper indexed match field.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Text fields with a huge unique value count\u003C\u002Fstrong> (like free-text notes) combined with wildcard searches (\u003Ccode>*keyword*\u003C\u002Fcode>), which can't use the index efficiently because the match could start anywhere in the string.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Why do sorts feel slower than searches on the same table?\u003C\u002Fh2>\n\u003Cp>Sorting has a different cost profile. FileMaker can sort quickly on indexed fields, but a sort on a calculation field, a summary field, or a field across a relationship forces FileMaker to compute or fetch a value for \u003Cem>every record in the found set\u003C\u002Fem> before it can order them. On a found set of 500 records that's invisible. On a found set of 100,000 records pulled in for a year-end report, that's the multi-minute freeze your finance team complains about every quarter.\u003C\u002Fp>\n\u003Cp>Another frequent culprit: sorting by a field that lives in a \u003Cstrong>related table\u003C\u002Fstrong> through a one-to-many relationship. FileMaker has to resolve the relationship for each record before it can sort — this is dramatically slower than sorting on a field that lives directly in the table being displayed.\u003C\u002Fp>\n\u003Ch2>How do you actually fix slow searches? A step-by-step approach\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>Turn on storage\u002Findexing for fields that need it.\u003C\u002Fstrong> In Manage Database, open the field's storage options and set indexing to "All" for fields regularly used in Find requests. Do this selectively — indexing every field bloats the file and slows down data entry, since every write now has to update multiple indexes.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Replace unstored calculations with stored ones where possible.\u003C\u002Fstrong> If a calculation only references fields in the same record and doesn't use \u003Ccode>Get()\u003C\u002Fcode> functions that change per user\u002Fsession (like \u003Ccode>Get(CurrentDate)\u003C\u002Fcode>), it can usually be made stored — which makes it indexable.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Add a dedicated, indexed "search key" field\u003C\u002Fstrong> for cases where users need to search across multiple concatenated fields (e.g. name + city + postcode). Populate it via an auto-enter or trigger, and search that single field instead of forcing FileMaker to combine several unindexed lookups at Find time.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Script your Finds instead of relying on manual Find mode.\u003C\u002Fstrong> A scripted \u003Ccode>Perform Find\u003C\u002Fcode> with a precise, pre-built find request avoids the overhead of the user typing loose criteria, retrying, and re-searching. It also lets you constrain the found set in stages — find broadly first, then constrain — which is often faster than one large complex request.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Avoid wildcard searches on huge free-text fields where you can.\u003C\u002Fstrong> If users constantly search notes fields with \u003Ccode>*word*\u003C\u002Fcode>, consider a separate indexed keyword\u002Ftag field populated at data-entry time instead.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Check container field settings.\u003C\u002Fstrong> If full-text search inside PDFs isn't actually needed, turn it off — it adds real overhead to every import and edit.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Re-index after bulk imports.\u003C\u002Fstrong> Large data imports can leave indexes in a state where FileMaker rebuilds them on the next relevant search — schedule bulk imports for off-hours, or force a rebuild afterward.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F290?w=700&f=webp\" alt=\"magnifying glass over database records, one path marked indexed fast, one marked unindexed slow\" 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 do you fix slow sorts specifically?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Sort on stored fields, not calculations\u003C\u002Fstrong>, wherever the business logic allows it.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Pre-sort at the layout or script level\u003C\u002Fstrong> by choosing a sort order once and caching the found set, rather than re-sorting the same records repeatedly inside a loop.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Avoid sorting across relationships.\u003C\u002Fstrong> If reports consistently need to be sorted by a related field (e.g. sort invoices by customer region), consider storing a copy of that value directly on the invoice record via a script trigger when the customer is assigned — a small denormalization that pays for itself in report speed.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Limit the found set before sorting\u003C\u002Fstrong>, not after. Sorting 500 filtered records is always cheaper than sorting 100,000 and then filtering.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Use summary fields carefully.\u003C\u002Fstrong> They're powerful for subtotals but can slow sorts and layout loads on very large found sets — test with production-sized data, not your 200-record development copy.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Does hosting and network setup affect search\u002Fsort speed too?\u003C\u002Fh2>\n\u003Cp>Yes — and it's often the real bottleneck, not the schema. A few things worth checking:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>FileMaker Server vs. peer-to-peer hosting.\u003C\u002Fstrong> Searches and sorts should always be evaluated server-side when the file is properly hosted; peer-to-peer sharing (one user's computer hosting the file for others) pushes far more raw data across the network and makes even indexed searches feel sluggish.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>WAN vs. LAN access.\u003C\u002Fstrong> Remote users connecting over a slow or high-latency internet connection will feel every unnecessary field on a layout, every unindexed search, and every large sort far more acutely than someone on the office LAN. This is exactly the kind of structural issue 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>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Layout complexity.\u003C\u002Fstrong> A layout with dozens of unused fields, portals, and conditional formatting rules re-evaluates all of that for every record in a sort or found set, even if the user never scrolls to see it. Trim layouts used for searching and reporting to only what's needed.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Server hardware and load.\u003C\u002Fstrong> A FileMaker Server under-provisioned in RAM will page cached data in and out constantly during large sorts — monitor server-side statistics (available in FileMaker Server Admin Console) during peak hours to see if this is happening.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>A quick diagnostic checklist\u003C\u002Fh2>\n\u003Cp>Before touching schema, run through this list on the specific find\u002Fsort your users complain about:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is the field being searched actually indexed ("All" in storage options)?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is it a calculation field, and if so, is it stored or unstored?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Does the search or sort cross a relationship?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is the layout used for this search overloaded with unused fields\u002Fportals?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is the file properly hosted on FileMaker Server, not peer-to-peer?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is the found set constrained \u003Cem>before\u003C\u002Fem> the sort runs, not after?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Has this been tested against production-scale data, not a small dev copy?\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FAQ: FileMaker search and sort performance\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Does adding more indexes always make searches faster?\u003C\u002Fstrong>\nNo. Every indexed field adds a small write cost on every create\u002Fedit\u002Fimport, so indexing fields that are rarely searched just slows down data entry for no benefit. Index deliberately, based on what users actually search.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can AI or scripting help beyond manual optimization?\u003C\u002Fstrong>\nYes — increasingly, teams add lightweight AI-assisted search layers (for example, natural-language lookups powered by a connected AI tool) on top of a well-indexed FileMaker schema to help staff find records without needing to know exact field names or wildcard syntax. This works well as an added layer, but it doesn't replace fixing the underlying indexing — a slow, unindexed table will still be slow under an AI front end.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Why is a Find fast in the dev copy but slow in production?\u003C\u002Fstrong>\nBecause found-set size and network conditions matter enormously. A find that's instant on 300 test records can be genuinely slow on 300,000 live records, especially over WAN. Always performance-test against realistic data volumes.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is it worth rebuilding the schema just for search speed?\u003C\u002Fstrong>\nRarely as a first step. Most search\u002Fsort slowness is fixable through indexing, field storage settings, scripted finds, and hosting\u002Flayout cleanup — a full schema rebuild is usually only justified when the underlying data model itself has grown incoherent, not just slow.\u003C\u002Fp>\n\u003Cp>If your team has quietly started avoiding certain searches or reports because "it's just slow," that's usually a sign the underlying field structure, indexing, or hosting setup hasn't kept pace with how much the solution has grown — not that FileMaker itself has hit a ceiling. Loggix regularly audits existing FileMaker solutions to find exactly which fields, relationships, or layouts are causing the slowdown, and can implement the fix directly, extend the solution with a connected web or reporting layer, or add AI-assisted search where it genuinely helps — all without forcing a rebuild of a system that's otherwise working well.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901677000,[19,20,21,22,23,24,25],"FileMaker performance","FileMaker searches","FileMaker sorting","database indexing","FileMaker scripting","ERP performance","Claris FileMaker","\u002Fapi\u002Fknowledge\u002Fimage\u002F376\u002F?v=dddfec780453",false,"",null,{"title":31,"slug":32},"FileMaker and Claris","filemaker-and-claris",{"title":34,"slug":35},"How to improve the performance and structure of a FileMaker solution","how-to-improve-the-performance-and-structure-of-a-filemaker-solution"]