I know this is long, but I have a lot to say on this subject. I have worked in high-level Tech Support for enterprise software for 10+ years. Support staff, if they’re doing high-level technical stuff, and not just parroting, “have you tried turning it off and then on again,” into a phone, are techy people. We like to solve problems ourselves; it’s what we’re good at; that’s why we’re in this position. If this isn’t true of Support staff who you have hired to do support that involves DBA-type work in live client environments, then you have hired the wrong people.
TL;DR: If Support can’t solve problems by themselves, then they don’t have enough time, skills, or access, or there is no workflow process in place that lets them know how they should be handling these types of requests.
You have used these terms to describe a Support staff: “feel overwhelmed” and “believe they can’t solve [some issues]”. Are they overwhelmed and unable to solve all the issues they’re being asked?
Are there enough people on the support team that they could, with the right skillsets, be able to answer all the requests that come in? If there are more requests coming in than is possible for the Support team to answer, that’s an obvious problem. Be aware that Support staff in understaffed departments have to do an algebra that looks like this: I can dig into this one complicated issue and leave 4 other issues unanswered today, or I can ask the developer in charge of this area for help on that one issue, and be able get back to all 5 issues. In my experience, the Support staffer’s preference would be to have the time to be able to dig into the complicated issue and learn about the product themself, but when there is no time, that isn't an option, especially if there are support SLAs you have to meet.
Are there requests coming in that require skills that aren’t present in the Support Team, but only in Development? You mentioned DBA skills. If there’s no one in Support who understands whatever you’re using databases for with your product, then it’s not going to be possible for them to solve the issues themselves (at least not in a timely manner; see the previous point). Get Support staff the training they need to solve the sorts of issues they’re being asked. If you can’t afford general training, have them sit with the developer they’d usually forward these sorts of issues to while the developer goes through the troubleshooting process so they can learn enough to be able to answer these questions themselves. Once you do this once, then the Support team itself should now have an expert in this area and other members of the team can ask that person, rather than the developer. If your Support staff does not have enough time to spend learning the skills they need to answer questions efficiently, then you’re back to problem #1 - not enough staff.
You mentioned requests for information. What pieces of information are your developers hoarding from Support? If there’s documentation Dev has that they’re not sharing with Support, then Support is going to have to ask Dev for it. If the information is available to Support, then Dev should just be able to point Support to it. This goes for the codebase, too. Is there part of the codebase that Support isn’t allowed to see? If so, you can expect more questions forwarded from Support about those parts of the product.
Now to discuss the process. There should be a Tech Support process or workflow. Probably a flowchart for each type of request with steps like: being assigned a ticket number, assigned a Support technician, escalated to the Support manager, escalated to Development, being resolved, etc. Each different type of request and condition should have its workflow mapped out. There is a place for Development involvement here, like when legitimate bugs are reported, or because we all know that there is that one Dev guy who is the only person in the whole company who truly understands [obscure authentication process] in [obscure environment]. Having the process diagrammed helps everyone see when Development involvement is appropriate.
Noticed I also put a Support manager in there. Does your Support team have a manager? While the Support team is learning their new process – i.e. how to become more self-reliant, they can make it part of the process to have escalations to Development have to go through a manager. To be honest, once the team is in the habit of exhausting internal options first, I think you’ll find that you won’t need this step, but while you’re changing habits, if can be useful to have someone within the Support team to help make the call on what’s worth bothering Development with. A Support manager should know the skills and schedules of both teams in order to determine when it’s appropriate to shift resources from Dev to Support. The Support manager is also who you (as the presumed manager of the Dev team) can have a discussion with when you feel that Dev is being called on too much by Support.
Finally, if you're super-concerned about how many requests are being passed to Development, you should be able to create metrics for this in your support ticketing system (you are using a ticketing system that tracks who's working on what issues and what the issue statuses are, right?) Metrics are not just for shaming the person in Support who asks the most questions of Dev (that Support technician probably takes all the hardest questions), but are also to look for trends, like "we pass a lot of questions about weird Oracle permissions to Dev," or "two weeks after a new release the volume of questions goes up, and we need to call in Dev resources." These can help find solutions like "get someone in Support some Oracle training" or "we are probably going to have to schedule for extra volume of Support requests x weeks after a new release."