We are having SP 2013 on-prem environment. We are planning to have few applications which are using SQL as a backend. Is it advisable to use the same SP SQL Server DB instance to create DB for other applications? Will it cause any performance issues?
As per the Best Practices from MSFT:
To ensure optimal performance for farm operations, we recommend that you install SQL Server 2008 R2 with SP1 or SQL Server 2012 on a dedicated server that does not run other farm roles and does not host databases for other applications.
But all of this depends on your existing usage of your SharePoint databases as well as the future usage of these non-SharePoint databases.
Similar issue post for your reference:
It isn’t best practice as per the documentation from MS but it can be done and as far as I could tell, it isn’t unsupported. There are a few things to note that might help you decide if it is worth it.
SharePoint needs certain SQL Server settings (such as Max Degrees of Parallelism) and if they conflict with the other applications then you can’t do it.
You also need to make sure you have sufficient resources.
We’ve been testing out putting our 2013 SP databases on a shared cluster. In this situation, our DBA doesn’t want our SP accounts having the high permissions it normally gets by default when setting up the farm. This means we need to request temporary Sys admin privileges before installing patches or even setting up a new service application.
Another thing we ran into related to how SP monitors itself. There are timer jobs that help maintain the DBs but these had to be disabled so our DBA could handle that instead.
The upside we are hoping for is some better redundancy as well as saving on some SQL licensing.
I would probably recommend a separate server if possible. An in-between option might be a separate instance on a shared SQL server.
Hope that helps.