The choice of how an application manages the logs is relative.
The best way is the one that has the least impact on your application or has a lower infrastructure cost.
Saving logs to the database makes data manipulation more flexible and accessible, including automating backups.
Another reason is that it has much longer durability and is in a supposedly more secure location than the DB.
Not to mention that it can be accessed from anywhere in the application if there is a page that lists the log data.
But there is a problem with that. Depending on how the log is implemented in your application saving it to the database can make it easier to create a bottleneck.
Exemplifying:
Imagine that you have entities that relate to the application and that every time that certain operations are performed, you need to log a database log next to that operation, and suddenly application performance begins to fall on account of the coupled generated between the log and the entities. And finally you end up having a performance bottleneck.
There are a few ways to get around this.
As for logging into files, depending on the size of the application can become very expensive to read.
Imagine a log file with at least 200mb in size?
The processing power of the machine that will read this must be great.
Although logging is much faster in a file than in the database itself, a counterpart is generated in the sense of reading.
Another disadvantage of logging to a file is that it is not visible in an application, it does not have easy access.
In addition, you can register locally to a file, and then migrate that data to a database if necessary. Or keep the logs in files and in the database.
In any case, the best way to store logs will depend on the need, context, and infrastructure.