How to optimize FileMaker searches and sorts

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.

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.

Why do FileMaker searches get slower as the database grows?

A 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.

The most common causes we see in real client solutions:

• 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.
• 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.
• 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.
• Related (portal) fields used directly as a Find criterion across a relationship instead of a proper indexed match field.
• 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.

Why do sorts feel slower than searches on the same table?

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 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.

Another 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.

How do you actually fix slow searches? A step-by-step approach

1. Turn on storage/indexing 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.
2. 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/session (like Get(CurrentDate)), it can usually be made stored — which makes it indexable.
3. 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.
4. 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.
5. Avoid wildcard searches on huge free-text fields where you can. If users constantly search notes fields with *word*, consider a separate indexed keyword/tag field populated at data-entry time instead.
6. 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.
7. 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.

How do you fix slow sorts specifically?

• Sort on stored fields, not calculations, wherever the business logic allows it.
• 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.
• 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.
• Limit the found set before sorting, not after. Sorting 500 filtered records is always cheaper than sorting 100,000 and then filtering.
• 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.

Does hosting and network setup affect search/sort speed too?

Yes — and it's often the real bottleneck, not the schema. A few things worth checking:

• 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.
• 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.
• 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.
• 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.

A quick diagnostic checklist

Before touching schema, run through this list on the specific find/sort your users complain about:

• Is the field being searched actually indexed ("All" in storage options)?
• Is it a calculation field, and if so, is it stored or unstored?
• Does the search or sort cross a relationship?
• Is the layout used for this search overloaded with unused fields/portals?
• Is the file properly hosted on FileMaker Server, not peer-to-peer?
• Is the found set constrained before the sort runs, not after?
• Has this been tested against production-scale data, not a small dev copy?

FAQ: FileMaker search and sort performance

Does adding more indexes always make searches faster? No. Every indexed field adds a small write cost on every create/edit/import, so indexing fields that are rarely searched just slows down data entry for no benefit. Index deliberately, based on what users actually search.

Can AI or scripting help beyond manual optimization? Yes — 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.

Why is a Find fast in the dev copy but slow in production? Because 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.

Is it worth rebuilding the schema just for search speed? Rarely as a first step. Most search/sort slowness is fixable through indexing, field storage settings, scripted finds, and hosting/layout cleanup — a full schema rebuild is usually only justified when the underlying data model itself has grown incoherent, not just slow.

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.