October 1, 2007
Alpha Five claims to clobber FileMaker 9 on SQL performance
The Alpha Five guys decided to test the performance of their software vs. FileMaker on queries to a foreign database, and published the results. Given that Alpha Five designed and performed the tests, I bet you can guess who won.
From a quick read, it seems all the tests were single-table queries, and some or all were designed to highlight the flaws of a specific design choice made in FileMaker (doing certain work itself when it would be more efficient to push it to the foreign DBMS).
Comments
6 Responses to “Alpha Five claims to clobber FileMaker 9 on SQL performance”
Leave a Reply
Curt – what alerted us to this topic was the different messages beign conveyed by the marketing folks at FileMaker when compared to the technical folks when Filemaker 9 was released.
When FileMaker 9 was released this summer, they described it as the “Most Significant Upgrade” in the history of their company, we were, as a competitor, naturally curious to see what they were up to. We were especially taken with their strong claims in the area of SQL support, which is an area that we are particularly interested in, given that a number of our development team were senior designers of Powersoft, which, in many ways set a new standard for working in a client-server fashion with SQL data when it was first released.
Quote from the Filemaker press release:
“The new version also offers breakthrough, easy-to-use tools so FileMaker users and workgroups easily can connect to the world of company and Web data residing in external SQL data sources: MySQL, Oracle SQL, and Microsoft SQL Server.
Their original PR is here http://www.filemaker.com/company/newsroom/releases/1303210.html
Their technical documentation which is here http://www.filemaker.com/downloads/pdf/public_techbrief_ess_en.pdf
states
“It is important to note that “increasing the potential size and scalability of FileMaker Pro based solutions” is not an explicit design goal of the ESS (External SQL Sources) feature set. It may be possible to use ESS in that way, but the feature set is designed to favor transparency and ease of use, not raw speed. So it is probably not wise to expect that a good use of ESS would be to replace your largest and most complex FileMaker Pro based tables with SQL-based tables. This might work perfectly well, and might even solve certain problems for certain systems, but it would be wise to proceed with caution and to remember that the feature designers were trying to achieve “smooth, FileMaker Pro-like integration” not “bigger, faster FileMaker Pro-based systems.” ESS is not designed as a means to allow a FileMaker Pro solution to scale beyond the limits of a purely FileMaker Pro based solution. The ESS feature set is designed to emphasize the seamless integration of SQL-based tables into a FileMaker Pro solution, rather than to take specific advantage of the high-scalability features of SQL back ends.”
Clearly, the marketing and tech teams at FileMaker are not on the same page.
Richard, it sounds as if you’re saying:
1. FileMaker introduced what they claim is important new functionality.
2. The performance of that functionality is questionable in its first release.
3. They know and admit that.
So it sounds as if your point boils down to:
A. #2 above.
B. “Hey, Alpha Five is here, and we already do well what FileMaker says is so important but hasn’t ironed the kinks out of yet.”
Is that an apt summary? 🙂
Best,
CAM
Curt
Good morning, Curt!
A question one has to ask is why would FileMaker make a big deal about FileMaker 9 having this great SQL support , making it the “headline” feature in their news release, when their tech people knew (based on their own whitepaper) that it has this fundamental flaw when it comes to sorting SQL data?
Performance matters to SQL developers, and regardless of why FileMaker doesn’t perform, the fact is, it doesn’t perform. Is this a design “error” or does this speak to a larger issue in terms of their understanding (or lack of it) of the needs of SQL developers?
Taking 5,400 seconds to sort a million records is more than “questionable.” It’s unacceptably slow in an absolute as well as a relative sense, especially when compared to what you get with Alpha Five: 8.86 seconds for the same test (or for that matter, any front end that follows a proper client-server model).
The reason we decided to announce our test results is simple. More and more SMB’s and departments of enterprises are looking for easy, fast ways to build Web and desktop applications, and they have to connect to SQL data sources.
What we worry about though, is one when of our friendly competitors (namely FileMaker) makes claims that are widely echoed in the media at face value, with no testing. People get excited, only to become disappointed when they actually try and use the software with a SQL database. And that has the potential to have a negative “halo” effect on everyone offering front end dev platforms for SQL backends.
Our goal was to point out that the problem lies in how FileMaker has engineered their product, and to illustrate that FileMaker’s problems in this area are not indicative of a broader problem suffered by other RAD tools (such as Alpha Five).
There are some other blog articles that go further in highlighting FileMaker’s failure to pay attention to the needs of developers. See these, for example:
http://www.servoymagazine.com/home/2007/07/commentary-file.html
http://bobcusick.blogspot.com/2007/07/filemaker-9-sql-link-ish.html
Hi Richard, and thanks for your further thoughts!
But don’t both those links come from partisans of a third contender (Servoy)?
Anyhow, the Bob Cusick post lists a number of FileMaker limitations. So I have to ask: Are any of those true of Alpha Five as well? 🙂
Best,
CAM
Does anyone even use Alpha products anymore? User forums are sparsely posted last time I looked. I was a heavy user of an Alpha Four DBMS years ago, and opportunities to use that experience have seemed slim over the years.
I’ve been disappointed in Alpha Five’s followup since our last contact.
CAM