Get a new set of friends.
I inherited an application where most of the business logic was in stored procedures. It's horrible. Here's why:
First and foremost, stored procedures are notoriously vendor-specific. Even Oracle and PostgreSQL stored procedures require some conversion to run on their opposite numbers and those are 2 databases that have more in common than almost any other. You may be
sure that you'll never run on anything but SQL server, but one day your boss may come and say "we got a good deal on hosting this app on Linux. How hard will it be to make it run under MySQL?".
Stored procedures execute on the database server. Often a single database server may back a dozen or more application servers. Database server boxes are generally pretty powerful, but do you really want work that could be spread out over a dozen machines all be forced to execute on the database box? Will your DBA come and kill you if you do? Will the CIO?
When you code an app with application logic in more than one place, it frequently degenerates into a treasure hunt. There's no "one stop shopping" for code. You have to determine which of 2 codesets in which of 2 languages you're dealing with and you may have complex interactions between the two.
Stored procedure code is a maintenance issue. It's likely that your
IDE doesn't allow stored procedures to be edited as easily as native code processes can be.
Source archiving and redistribution can be a MAJOR issue. DBMS's don't generally provide good support for keeping the stored procedure source code in a traditional version control system. And I've run into serious problems when people send me a zip file of "source code" and half the source code isn't there (because it's in someone's database locked up in their datacenter).
Stored procedures have some very important uses. But power lack that needs to be used judiciously.