February 20, 2026 at 4:26 pm
hi , i hear more and more that we have too many connections to our servers. many are sql. many arent.
so we are told to use api's where possible.
Isnt there a connection behind the scenes when an api is asked to return data from whatever the erp's database is>
February 20, 2026 at 4:50 pm
Yes there is. But perhaps the desire is to remove direct database connections.
February 20, 2026 at 5:58 pm
thx phil, are direct worse?
February 20, 2026 at 6:51 pm
thx phil, are direct worse?
it depends.
first one could cause issues with api calls as well - but api server can throttle calls if needed even if the caller was irresponsible enough not to implement it themselves.
and then there is the notion of what constitute too many calls. 10k connections per minute or per hour or per day?
February 20, 2026 at 7:10 pm
APIs usually pool the connections; I think this happens automagically. So it's not one connection for one user but many connections shared by all users. Like most things that happen automagically, sometimes they don't do what you expect and you have to do some tuning. So if the app isn't pooling connections or is pooling them in an inefficient way, you could end up with "too many connections".
February 20, 2026 at 8:24 pm
Another question for you is what problem are you trying to solve and how will you know it is solved? "Too many connections" is very arbitrary and not helpful. BUT "Too many connections causing measurable performance issues" is helpful. Get the measurements, build a test environment and do some testing to see if the API helps OR if those performance issues were caused by something else. MAYBE it makes sense to have a dedicated server for the SQL instance since you say many of the connections aren't SQL related.
Fixing something because someone read a blog once that direct connections to SQL are bad and you should use API's instead MAY not be a good scenario for your environment and/or use case. We do direct database connections for most in-house apps and things work fine and the only time I notice issues is with a 3rd party connector (ie an API) being used to allow cloud systems to talk to the database. So in my specific scenario, the API is causing more problems but thankfully the software using the API seems to handle things well and the rollbacks are not a big deal - they are simple SELECT queries that get deadlocked and rolled back.
Before making drastic changes to your environment (implementing API server(s) to handle connections to SQL), I'd first make sure that there is an actual bottleneck that the API's will help solve.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
February 20, 2026 at 9:40 pm
Exactly! Like my dad always said "If it aint broke, don't fix it". In SQL Server, the corollary is "if you don't know your change is going to make it better, don't deploy it to production."
February 20, 2026 at 9:45 pm
I've had a few customers do this and they just move the load. Unless the API server caches results for its connections, you still have a lot of queries to the db.
In fact, sometimes you get more because people make more API calls thinking they are free.
Viewing 8 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply