Yep - this is a safe assumption and Airtable could have managed this better. But there have been warning signals here in the community going back as far as 2018. Inexperienced database makers don’t typically think about the architectural consequences of using a feature designed for internal use in an external dependency.
Airtable promised that you could upload attachments as “copies” of documents and images and they have upheld that promise. They never promised immutable and sustained addressability to those attachments outside of the Airtable UI. This is the gotcha’ moment that everyone is surprised about and some of us saw it and warned of it for many years.
I’m surprised you’re all surprised.
I did a quick search and I alone have warned of this delicate and likely-to-vanish pattern 27 times in this community. Most of my threads are related to API-uploads that are unreliable. And in those specific threads, I advised clients and all users to consider the idea that in mission-critical applications where there is a distinct dependency on binary artefacts, you best address them by REFERENCE, not by VALUE.
The key takeaway is that it was never a good idea to lazily make copies of artefacts. Imagine a 10k image, a 100k image, and a 100GB video. At what point do you realize that making copies is impractical? Sadly, we use size as a justification for convenience and tolerance of the laziness Airtable has afforded us historically. It’s just 100k - no big deal, right?
As it turns out - it’s a big deal irrespective of size.
Binary assets are best integrated into data systems by reference, not by value. The requirement to manage digital assets separate and apart from the data model always existed; we just chose to sidestep those requirements for simplicity, faster time-to-production, and for our own profit of course.
The party’s over.
