Actually, FileMaker DOES support ACID through transactional database practices. Nobody around here really refers to it as ACID though. The methods FileMaker uses may be a little foreign to SQL developers, but it's there if you want to create it. Here's a good read on it:
Thank you for being open though, and coming here to seek a second opinion.
Your concern with large record sets is valid, it's the ability for filemaker to create a simple front-end on ODBC data that results in it's general slow summary operations.
There are however ways to work with large data sets. Filemaker ESS (SQL data sources) does support the use of SQL views, which can greatly reduce the number of records you see into a much smaller data set. Furthermore, you can generate caches of summary/calc data server side, to take away a lot of the work that is regularly "slow" when filemaker sends data to the client for evaluation.
I don't have a great understanding of Mulesoft, but I thought it was used for creating APIs, and NOT for creating user-interface driven apps like FileMaker. You haven't really explained much about what you're trying to DO with your data, and that might help us to make your case for FileMaker a better one.
It might be worth your time to meet with a FileMaker consultant as well to continuing a second opinion.
I have set up a number of ODBC connections between FileMaker and MS SQL Server, Oracle and MySQL. The biggest issues are getting proper drivers and making sure you have the correct version of the databases, but if you do, the connection works well and reliably. One of my most often requests is getting FileMaker to talk to some web MySQL database and while this works, if the connection is via the wide area network over the internet, performance can be pretty lackluster. I have several situations where the SQL database is on the same switch just one hop away and then it seems to work amazingly fast.
I find quite a few SQL database consultants who at best know of FileMaker from back in the 1990s and really do not understand its current power or how FileMaker handles transactional data (see Mike's comment above).
FileMaker is not the be all to end all, but I find it more often dismissed by people who do not really understand the framework and how powerful it really is.
Keep in mind all consultants, including FileMaker ones, tend to recommend what they know well and use. Its like the old saying, if all you have is a hammer, then everything looks like a nail. You would not ask another framework person to comment on FileMaker and vice versa. If you want to know what FileMaker can do for you, check with a FileMaker consultant.