I would be careful with the term "cause". There is a symbiotic relationship between the application and the database. Or, if talking to a DBA...a database and its applications. Most databases can store any sets of arbitrary information...but how they are stored (read: structure) must take into account how the data is to be used. When the database designer can be told up-front (by the app dev team) considerations can be made to optimize performance along whatever vector is most desired (e.g. read speed, write speed, consistency, concurrency, etc). Most database performance issues result when these considerations are left out. Related: Just because a query works (ie. returns the right data) does not mean it's the best query.
Client/front end guys: "you need to fix this query, it takes 10 minutes to run and the front end is timing out"
DBA: "err, this query wants to return 50,000 rows"
C/FEG: "yes, and?"
DBA: "what in blue blazes is your UI, or a user, going to do with 50,000 rows?"
C/FEG: "oh - we hadn't thought about that ..."
If your database is great, at least you have the option of a fast backend.
More generically, state stores are almost always bottlenecks (they tend to be harder to scale without some tradeoff)
Also, in my experience, the database is almost always the main cause of any performance issues. I would much rather hire someone who is very good at making the database perform well than making the front end perform well. If you are seeking to be a full stack developer, devote much more time to the database layer than anything else.