Ok, my bad. Let me rephrase that – operations like contains, soundex, regex, or any formula based search cannot be handled with an index, only with an exhaustive search of every record. For disk based programs, the difference in performance between an index based search and an exhaustive search is very large. In the past, disk based database programs simply didn’t allow for exhaustive searches because of the performance issues, but I see that now some of them do.
Here is a Stack Overflow post that discusses this:
The answer on this page by Johan is especially on point. Notice that he mentions that:
SELECT * FROM t WHERE a LIKE '%a%'
cannot use an index – this is the same as Panorama’s contains operator.
By the way, this page seems to indicate that Regex in MySQL doesn’t support Unicode:
As for FileMaker, it indexes based on words in the data. So searches based on words (or beginning of words). Any other kind of search will not use an index and will be very slow.
It’s not clear to me that the FileMaker regular expression plugins you linked to can be used for searching. They talk about applications like parsing email addresses, not searching. If they can be used for searching, they will be very slow.
I couldn’t really figure out the Soundex plugin for FileMaker, I’m not a FileMaker expert. It does mention “similar sounding content in your database”, which sounds like searching. But it seems like it just takes one text value and calculates a number. Perhaps you could make a calculated field based on that, and search the calculated field?
The bottom line is that because Panorama is RAM based it is much faster than disk based databases at exhaustive searches (searches where every record in the database must be examined).