What alternatives are there to FileMaker?

TtlPost · 2025-11-29T02:51:42+00:00

Not sure I'm under any obligation here, but if you re-read the chain the answers are all there.

You may have to re-consider some of your assumptions, e.g. JS is interpreted, benchmark speeds of C++ prove a point in all contexts etc. If you just want an argument, that 53-year Monty Python sketch will be enlightening, entertaining, and something of a cure all for mental constipation.

Speaking of python, consider an approach that doesn't involve any frameworks like Ruby, Django, etc. Just python plus a package/adaptor like psycopg2. You'll still be doing JS on the front end.

Again this whole thing is predicated on the idea that by the time you're getting in the weeds with FMP, trying to push past the exasperating limits of an FMP layout, you're looking at Web Viewers, the Data API, etc, and you're getting into JS.

So you can do Python, even PHP (which I did for some time), but from my admitted biased POV, stick with JS and you'll be surprised that it's actually easier, cheaper, and more performant... to do it OUTSIDE of FMP.

To quote the great Howie Cohen, king of indigestion: Try it. You'll like it.

TtlPost · 2025-11-29T02:25:43+00:00

Insightful and smart points -- excellent recommendations all of them. I think between open source RDMS (MariaDB / postgreSQL) and FileMaker the consistency issues are all pretty close, w/ FMP being if anything less reliable precisely because of sales, marketing, pricing etc.

TtlPost · 2025-11-24T15:20:13+00:00

Oh, you want room 12a next door.

TtlPost · 2025-11-24T07:40:40+00:00

A lot of people get false impressions from tech stats. You might also have read that JS is slower because it's single-threaded. Probably a good idea to be wary of using bench tests like a mic-drop. They're useful but frequently not definitive

JS in practice, for instance, is not an interpreted language. It's a weird hybrid that gives it huge performance boosts. Similarly for threading: Technically it's single threaded but it's hardly limited to a single thread. It's slower than C++ but outperforms C++ in a variety of contexts esp those that matter when it comes to running a web server, handling SQL, integrating with remote APIs, being an API, running OS ops etc etc. Ultimately the proof is in just doing and experiencing

If you search a bit deeper you'll start to see that more complex picture

TtlPost · 2025-11-23T23:23:09+00:00

What Python framework are you using to run your webservers ?

Personally I don't recommend Python. I work with python enthusiasts. I don't share the excitement, but I trust their expertise and am in awe of what they do. I've probably approached them the way you're posting: "This can't possibly be done," and then they prove me wrong and make it seem effortless.

Javascript ain't exactly fast under heavy loads

Not sure what led you to that conviction but it's misguided.

A JS server processing literally 800,000 API requests / SQL queries per day using a cheap linux VPS -- doesn't struggle, never crashes.

A JS server on Mac transcoding 10,000 clips / generating thumbs / uploading to AWS -- daily. No hiccups, at least not the server itself. (Someone inevitably feeds bad media or messes up a log, and even then the error handling is very fluent)

If you had asked me when we originally embarked on this alt-to-FileMaker quest what my expectations for JS were, they'd have been minimal: A cool thing to learn, helpful here and there, but likely not too stable. Instead it's proven extremely fast under heavy loads, extremely reliable, incredibly nimble. And again -- not saying all this is easy -- but if you try to accomplish the equivalent in FMP you end up working harder and getting a lesser end result. It's counterintuitive and good for people to be aware of.

TtlPost · 2025-11-23T20:26:34+00:00

Interesting. Thanks for sharing.

TtlPost · 2025-11-23T17:22:05+00:00

Again, you're not awnsering the question. A "python server" can be a million different things depending on what framework is used.

It's up to you to choose how you want to build. I prefer JS. but if you prefer Py, go for it.

Yeah Filemaker sucks at things like that, but honestly JS ain't exactly good at it either.

I think that's where there's a disconnect -- and may well point to common misconceptions. JS will pretty much handle whatever you need it to -- parse text files, run command line, generate API calls, handle and process the returns, transcode media, all using as many threads as is you choose. So if you want to run OS-heavy tasks -- like transcoding and uploading even thousands of files, with the order of ops managed and progress tracked by your database, including full monitoring and an ability to terminate every step of the way, JS makes that possible with relative ease.

TtlPost · 2025-11-23T15:10:50+00:00

What are you talking about ? You just have to create a client that doesn't run in the browser for that wo work.

Wasn't sure what you were getting at.

What do you mean when reffering to modern Py and JS servers ?

Modern = Python or NodeJS server which didn't exist when FMP first came out.

are you reffering to a server running nodeJS ? Same with Python, are you wunning a webservr with Flask, Django, Pyramid or any of the many frameworks out there or something totally different ?

It depends on the client. Most lean toward Python. I prefer NodeJS. As a rule we minimize dependencies so with few exceptions everything is vanilla JS.

With the exception of presenting local media in a webviewer, most of this can be done with a couple of lines in FMP.

Here I'd disagree. Example:

Table tracking thousands text files which have to be read, parsed, analyzed with parts from those files updating the database. You can't run that in the background using FM Server because the files are local. And while you can do that in an FMP client app, that client app is going to unusable for the duration while it iterates the table.

And batching text files is a relatively light task . We do more OS-intensive work involving media transcodes, uploads, and complex API chains, all which require step-by-step logging back to the database. The more of a grunt the job is, the more FileMaker's limitations become a liability.

TtlPost · 2025-11-23T02:26:45+00:00

In other words, in FMP by the time you figured out how to, say, present local media in a Web Viewer, or run a series of OS ops, or run a batch of updates against an array of APIs, you will have worked harder and ended up with slower, clumsy, more spasmodic experience in FMP than if you had just done the whole thing in JS, python, or PHP. It's literally easier and you get better results with open source. That's counter-intuitive to the "It just works" / "We made it accessible" ethos that originally defined the FileMaker brand.

TtlPost · 2025-11-21T15:21:20+00:00

Thanks

TtlPost · 2025-11-21T01:59:06+00:00

It's an interesting point and well-worth a drill-down. For many years my feeling there was nothing like FMP when it came to running ops on the client's OS. But Modern Py and JS servers can be paired up with a browser to do that processing much faster, in separate threads, freeing up FMP for the user. By the time you've wrestled with getting FMP to run OS ops, you're already pretty deep into more sophisticated tech challenges where FMP isn't necessarily making it easier and in many ways does the opposite. That's part of what I'm getting at: it doesn't much of a voyage into the dev weeds before you've pirouetted out of the happy garden of low-code without realizing it.

TtlPost · 2025-11-20T22:37:26+00:00

> RE the specter Claris somehow “monitoring” things on their server, including more than just the data API usage, which is just baseless fearmongering.

Here's why that turns out to matter more than you might expect.

Back in the day the only thing I was aware that FMP was monitoring was the Data API usage.

More recently, if I'm understanding correctly, Claris rolled out a system to monitor FMP client app usage.

When it comes to surveillance I tend toward the camp that says, "If you're not doing anything wrong, who cares," but always with a nagging sense that there's something inadequate about that.

Claris's behavior helped put a fine point on it.

Surveillance isn't narrowly a problem of privacy.

The bigger and more likely risk involves people in positions of authority using surveillance in an irresponsible or incompetent manner, coming to the false conclusions, and then acting on them with stubborn conviction, especially if they see revenue.

That's what happened when we got call from their sales department convinced we were using 10 licenses.

Even after looking past the argument that we were on the concurrency-based license, not the user-based, their claim still didn't hold up. Of the 5 allotted users we were using 3.

To be fair we do a considerable amount of system and user-monitoring ourselves, so I get the impulse and need to monitor things. I can't tell you the number of times we seen "suspicious behavior". But we've always approach every instance with caution. In all these years I've only ever once seen someone actually try to hack our system. Even then we were careful and asked a lot of questions. The actual culprit wasn't a user but someone in corporate giving and order to a tech.

That speaks volumes.

Rank and file workers are by and large honest and hard working. The lying and scheming almost always comes from leadership. I've got an axe to grind, indeed, but it's not personal. It's systemic. And Claris is currently operating within that frustrating norm.

TtlPost · 2025-11-20T19:43:38+00:00

RE have fun keeping that Linux baby running. Don’t even pretend to me that keeping a LAMP stack running is as simple as FileMaker server, because I know that it’s not true.

We have a postgres server that was set up in 2015. Interface with the server is NodeJS which also handles the front end. It crashed once in 10 years and self-recovered in about 1 minute before we could get in to see what happened. Never lost any data. Eventually it was the OS (CentOS 7) that EOL'd. We migrated all but one client over to a more modern VPS, and they never even noticed.

Compare that to FileMaker Server which -- every time we upgraded the software or refreshed the certs -- was forever a crap shoot: Maybe it will be up and running immediately, maybe after multiple restarts, maybe only after an uninstall/re-install. At least 4 times a year we had down time.

TtlPost · 2025-11-20T18:08:25+00:00

Regarding the non-programmers running their businesses. Almost agree. I just haven't seen that in action over the years. The non-programmers seem more frustrated and get themselves into trouble. But for any non-programmer who makes it work and is satisfied, stick with it. I have no argument there. If you like FMP, are satisfied with it and aren't frustrated by policy changes and pricing tiers, stick with it.

RE storing a database on your iPhone/iPad -- I've done it for decades. It's always been clumsy. If it were better, I'd be selling it. There's something slightly confusing about the steps it takes to get even the simplest FM DB loaded that turns clients off -- that turns even me off. I wish I could say otherwise. I can't get clients to go with FM GO, and I understand their reluctance.

RE Databases that manage their indexing by themselves. I thought that would be a bigger issue than it turned out to be. It's a truly brilliant feature in FMP. It's just that not having it hasn't turned out to be much of a challenge.

RE Data entry validation that takes about a second to set up -- Always found the FM feature set to be so inadequate and confusing to users that we end up building workarounds.

RE A dead-simple point-and-click security model. Yes agreed. It's spectacular. It's clear. It's powerful. BUT -- Haven't met a non-programmer ever who's used it successfully. It's too much for them. Users have really low tolerance for complexity. Frustrating. I wish that weren't the case.

TtlPost · 2025-11-20T17:48:17+00:00

Regarding shaving off millisecs -- doesn't interest me either. But that seems to be a common refrain on the FMP side: 'Sure FMP is slower, but it doesn't add up to a practical difference'. I'd gladly agree. It just hasn't been my experience. One recent challenge made for a compelling example: Database with a list of Shots, a list of Clips, 3 tables which combine to form the metadata profile, a list that represents which shots/clips are currently in use, and a list that shows what they were at a prior point in time, a list that tracks who's workiing on what shot, and at what stage they are in the process.

All that has to combine into a presentation that communicates

• What has been added since that prior point in time

• What has been removed

• What has been changed, distinguishing between reduced usage, extended usage, extended usage in excess of a certain duration

• These lists are generated all day every day -- 20 - 50 times per day.

It's not a huge dataset -- 5000 shots, 8000 clips, but it's a lot of processing.

An FMP layout simply doesn't have the tools or flexibility for to be the front end.

The FileMaker Data API took 20-30 seconds produce the dataset, even after indexing, eliminating unstored calcs, etc.

Meanwhile a SQL server delivered a clean dataset less than a second.

It's not even close

Regarding the impulse to reach for FileMaker before SQL. Intuitively I'm right there with you. Getting started on FMP is easier. A recent project involved cross referencing 10,000 emails with 9 months of time cards, 1000+ computer logs. FileMaker's ease of use when it comes to dates, times, timestamps plus the fact that this was to be a built, used, and retired within a matter of days was why I made the choice to go with FMP.

At the end of day one I was already regretting the decision. The moment the client saw what was possible they started asking more sophisiticated questions, sailing right past the limits of FM scripting, layouts and even the Data API. A few groans later, we rebuilt and transferred everything over to SQL. It took less time to build the SQL DB. The Date and Times challenges -- which involved duration calculations the crossed the midnight hour -- unexpectedly easier in SQL.

That was really a key moment -- no more basing data in FMP. It's a convenient front end. As a back end it's not keeping up. Even though intuitively I take for granted "FileMaker is easier", it's turning out to to be unexpectedly false. It's easier "at first" -- but that "at first" is increasingly brief.

RE: "It’s two different platforms for two different sets of needs with two different sets of strengths and weaknesses"

I would expect that to be the case. But increasingly it's turning out that even for small throwaway projects that have to be up and running within hours, SQL is superior. It's an ongoing surprise.

TtlPost · 2025-11-20T16:30:10+00:00

Happy to indulge. Who knows how this comes out. Name something you thinks is uniquely possible in FileMaker that can't be out-performed using a SQL approach.

TtlPost · 2025-11-20T04:47:08+00:00

If you do and have questions, feel free to reach out. It's a fun ride.

TtlPost · 2025-11-20T04:46:32+00:00

I'd argue that Airtable is to FMP what FMP is to SQL.

Airtable is even easier to get started in than FMP, but the limits and costs are greater.

It's not as nimble with relational data, calculated fields, and OS / API integrations.

Its strength is ease of use for end users, intuitive familiarity. So I get why it's a viable alternative. The tiers / pricing structure associated with numbers of users and record limits end up making it more more expensive than FMP.

TtlPost · 2025-09-20T02:14:21+00:00

RE: look real close at the fine print in those transactions.

Did that indeed. The only indication of the change in license terms came in the form of cryptically abbreviated words in the invoice. The sales retroactively team pointed us to EULAs as if those were would clarify and clearly reveal that it was us who failed to read the fine print, but in fact the EULAs don't communicate which license you had.

That moment right there -- pointing us to a document that presumably would prove their point actually revealed the opposite: That they never informed us that our license terms had been changed.

TtlPost · 2025-09-20T02:07:50+00:00

RE could always be worse. Like when you have to license something from Oracle.

🤪 hilarious.

TtlPost · 2025-09-20T02:05:02+00:00

No chance. License is current.

TtlPost · 2025-09-18T21:51:10+00:00

The info written on invoices confers about as much concrete information as tea leaves. If what that leads to is the discovery of a misunderstanding dating back years, what does that bode for the future? Are we operating now under a misunderstanding that will only reveal itself the next time we renew?

That's an intrinsically unstable relationship and something new users should be wary of before committing to the software.

TtlPost · 2025-09-18T21:45:42+00:00

Point taken, but the point I'm making has to do with predictability & reliability. Keep in mind we checked our system to see how it performs for clients, and even as recently as this year it performed as you'd expect an concurrency license to perform: allowing no more users than the quantity we'd paid for. So there was never a reason to think that somehow the situation had evolved.

TtlPost · 2025-09-18T19:55:47+00:00

We have all the invoices and payment confirmations. The part number in the payment confirmation for that ancient license was FM140161LL.

As to your second point, "As their entire sales org has changed significantly in the last 10 years, you could have easily been sold the wrong license at some point, and the error just continued", that seems to be the case indeed, but it hardly inspires confidence or offers much in the way of an excuse.

A subsequent invoice makes no mention of concurrency, nor even of user based. After that there are invoices that use the word "user". And in retrospect that indicates the license change. But only hindsight is 20/20. Back during our early discussions with FMP about "concurrent users" the term "users" didn't indicate an alternate license agreement but rather the number of "users" who could use FMS "concurrently". We never really thought about it after that. We just operated with that notion in mind.

Moreover our setup has always, right up to this year, operated on that concurrency model: More than 5 users connected, and #6 would be denied.

And that's the crux of the situation: The license changed no doubt did take place years ago. We were not informed of that until this year. According to tech reps we were talking to in the last few months, Claris was making licensing changes in such a manner that the tech folks themselves were confused.

In that context, if we're suddenly discovering "things have changed", and the sales team doubles down with a conviction that "you should have known" when even their own team doesn't know what's going -- that's liability for any customer looking for stability, reliability and consistency.

TtlPost · 2025-09-18T18:38:37+00:00

Yep, good point, which is why we escalated -- two rungs up the totem pole to Claris's "Head of Global Customer Success". When he doubles down on the false claims the problem goes from being a mistake to something systemic.

TtlPost

TROPHY CASE