It looks like the two previous answers to this question more or less strongly recommend to turn on SSL anyway, but I'd like to suggest a different reasoning angle (although I'm not recommending not to turn on SSL).
The two key points in assessing whether you need SSL or not are (a) what SSL protects you against and (b) what the thread model is: enumerate the potential threats.
SSL/TLS protects the transport of information between a client (in this case, your web server) and a server (in this case, your database server) from tampering and eavesdropping by anyone on the network in between (including able to get on those two machines).
To assess whether SSL is useful, you need to assume that the attacker is in a position to perform the attack SSL is designed to protect you against. That is, the attacker would need to be in a position to sniff packets on the network or on either machines.
If someone in a position to sniff packets from the database server, they're likely to have root/admin access to that server. Using SSL/TLS at that stage will make no difference.
If someone is in a position to sniff packets on the network between the web server and the database server (excluding those machines), using SSL/TLS will prevent them from seeing/altering the application content. If you think there might be a chance this is possible, do turn on SSL. A way to mitigate this would be to use two network cards on the web server: one to the outside world and one to the inside LAN where the DB server is (with no other machines, or in a way that you could treat them all as a single bigger machine). This network forming the overall web-farm or cluster (however you want to call it) would be physically separated and only have one entry point from the outside: the web server itself (same principle for a reverse proxy head node).
If someone is in a position to sniff packets on the head node (the web server) itself, they're likely to have root access there (processes run by non-root users on the machine, shouldn't be able to read packets that are not for them). In this case, you would have a big problem anyway.
What I doubt here is whether enabling SSL actually protects you much in this scenario.
Someone with root access on the web server will be able to read your application configuration, including DB passwords, and should be able to connect to the DB server legitimately, even using SSL.
In counterpart, if you did assume that this warrants the use of SSL (because it might be harder to look into what the processes actually do rather than just looking at the network, even if you have root control on the machine), this would mean you would also want to turn for localhost communications (e.g. if you have other services on your web server, or in the situation where both DB server and web server were on the same machine).
It's not necessarily a bad thing to be over-cautious, but you have to put your question in the context of what attackers could also do should they be in a position to perform an attack against what the security measure (SSL) protects you against, and whether this security measure would prevent them from achieving their goal anyway, once in this position.
I think the window is actually quite narrow there (assuming your back-end network really is secured, physically, not just by some firewall amongst a number of machines).