Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am coming from an application development perspective (my day job) and not an infrastructure, or operations, perspective, so if this is a completely inane question, please let me know!

We have proxies in front of our application servers and this has typically served us well. This (hardware/software) proxy provides an abstracted endpoint (in addition to other services, such as load balancing/distribution) so that our clients always know how to connect.

Does anyone have any experience putting a proxy between application servers and the the database?

Seems like someone has got to be doing this, especially in hosting provider, or cloud space, but when I've talked to our (enterprise) infrastructure teams they just say 'no' though I'm still struggling to understand why.

I don't understand if due to the extra layer of abstraction in front of the database this causes functional or performance issues, or just plain makes it harder to trouble shoot when things go wrong.

Can anyone share thoughts, experiences, or resources in this area? I would greatly appreciate it!



share|improve this question
up vote 1 down vote accepted

I also like TomTom's DNS idea. Short TTLs and this is easier than you're making it to be.

But you can certainly run a proxy in front of your databases. SQLProxy and HAProxy can do this, for example. But again, if your concern is not load balancing or separating reads and writes, why add this extra level of latency (to and from the proxy) when you could just do it with a CNAME -- and I think that the argument is the one your Ops/Systems guys will consider.

share|improve this answer

Main problems:

  • Database connections are way more persistent between application servers and backends - so load balancing is hard through them.

  • Proxies mus tspeak the protocol. There are tons of HTTP proxies there. Try getting one for for example the SQL Server protocol. No need, no market - no product.

  • Finally, though what SQL Servers are, caching is not possible. Not without a protocol to invalidate results etc., and that is not part of any SQL implementation. No "if modified since" tag. Ergo, you would either gain nothing or deal with outdated data - both not acceptable on that layer.

share|improve this answer
Thanks for feedback! I might need to update my question w/more detail. I'm looking for a passthrough proxy to the server/cluster name (no caching, balancing, distribution, etc). Just looking to create a virtualized name that never changes. Server/cluster name can be rolled into/updated in VIP as needed. I didn't think about the protocol being an issue. Isn't Sql Server (e.g.) just tcp/ip? I"m guessing there is more to it than that! :) – Zach Bonham Sep 23 '10 at 18:51
Yes, it is just TCP/IP - but if you cache on that level, you basically gain absolutely nothing except some manageability, which may not be worth it. – TomTom Sep 23 '10 at 19:28
Do not use a proxy. Just use a CNAME to the server with the database name. Then you have a stable server name (similar to db name) and connect to that one. No proxy needed. – TomTom Sep 23 '10 at 19:29
Using Microsoft Cluster Services, that makes a VIP and DNS Name for the cluster, the client never knows what machine in the cluster is being used. – mfinni Sep 23 '10 at 19:55
Sadly that does not really solve anything in the larger scale... like moving databases between server (clusters)... AND it adds a LOT in terms of hardware requirements (shared storage) and nothing for uptime. – TomTom Sep 23 '10 at 20:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.