Your confusion comes probably from the fact that databases, especially normalized relational databases, when seen as a component, typically provide very broad interfaces. Any public table, any view and sometimes also stored procedures represents an interface on its own. So except for trivial databases, depicting each entity with an interface symbol is not a useful level of abstraction - it would just become an unstructured list of all the DB entities.
Now if your accessing application (like the backend app from your example) is just one black box, not easily to be split up into different logical components, and the whole thing accesses the DB model arbitrarily at will, than you cannot do much better than modeling the DB as one interface, with one symbol, and no specific name. I would actually consider to omit any name, a name like "persistence" does not really provide any more information than no name at all.
However, if the accessing clients are lots of different applications, each one responsible for a different subgroup of the entities in the DB, and each one a logical or physical component, it may make sense to model the DB with individual interfaces, each one for each subgroup, and each one with a unique name which distinguishes its purpose from the others. Or, when there is a microservice architecture, where each service has a database or data storage on its own, each service together with its DB can be modeled as a component. For this, each interface symbol is going to represent the whole API of one service/component.
So in short, component diagrams are best suited for component based architectures. If your application or database has not enough substructure, or if you modeling it at a level of abstraction where this substructure is not visible, a component diagram is not particular useful.
