Hello!
Is it reasonable to assume all applications that are data heavy (e.g. a Product or Transactions tool with a GUI or web frontend) will have a database running in the background? Or there are other ways to manage data under an app?
I assume the app can function by sending API queries to another app or web but is it reasonable to assume in every case, when we are talking about several records, there should be a database somewhere in the fullstack?
Thanks!
You have answered your own question
If you use the term data heavy then natural conclusion is the need for a data-base
But why do you ask this question? What are you trying to solve?
Is this an interview question , a work space debate?
Are you having performance issues?
Is the app the main source of the data?
Database can mean many things to many people . I would love @JeffModen to chime in, he always has great insights
I am trying to access the data bypassing the tedious frontend GUI so I wondered if I can just connect to the db and run SQL. If that is not an option, pulling data via API queries will be more inefficient if the right API bindings and functionality/documentation does not exist.
I wonder if any limitations or security concerns exist in that approach.
Who is the owner of the data?
Is the data sql server?
Is it a commercial product and are there legal/licensing issues as to the use of direct access to the db?
Etc
To answer the first question there, I try to never assume because it almost always gets me into trouble. If they're reading anything about data from a disk, then, by definition, they're using a "database"... which might be nothing more than a text file. It doesn't have to be a "Relational", "Hierarchical", or even a "Document" database. It can even be some proprietary format. You just can't assume what type of database it will be. I guess that also answers the second question in that.
And then there's the issue of how the data (database) will be accessed. A lot of people make the mistake of "By ORM Only" access and so they really miss out on some really high performance possibilities of stored procedures and some of the really cool but proprietary stuff each RDBMS seems to provide as a deviation from the ISO/Ansi based standards. They do so in the name of "portability" but frequently kill themselves when it comes to performance and resource usage. I'm going through that very thing with a 3rd party product right now. They, apparently, don't even know how to use an ORM well. 
The bad sidebar to using stored procedures and the like is that people think a database, regardless of which form it takes, is just a place to store data and so they think they know it all when it comes to SQL in all of it's glorious forms. And so they make the problem as bad as or even worse than relying solely on an ORM (and some folks have seriously figured out the right way to use an ORM but it's still an ORM).
IMHO, an ORM should only be used for C.R.U.D. operations and to call stored procedures.
And, when you read all of that, understand that I used to be "Front-Ender" a long time ago. I love working with and helping Developers and work very closely with the good folks where I work. I also know what they have to go through and why, in the past, they avoided SQL like a bed of hot coals. They no longer feel that way... they understand that a database is not just a place to store data.
Thank you for the very kind words. I hope I lived up to that expectation.