How much privacy does the default (I think it's 4) give?
If not enough, how high a mixin is enough?
It will always be a sliding scale, much like how many confirmations will give me full security? The answer is neither can give you "full" security, but they can make it so that it's enough to thwart even the most determined attacker.
Right now RingCT hasn't been rolled out so privacy is "OK", but once it is in effect it will not only obfuscate better, but also allow users to use much higher mixins without having the transaction size explode.
Really at the end of the day it all depends on your needs, if you send round numbers, a mixin of 3-4 will be fine for a regular user. It you are actively trying to hide your tracks, say from a person you are sending money to so that they can't trace the funds back to your previous transactions, then maybe a mixin of 8 to 10. It all depends on how imminent the intent of unveiling you is and how sensitive the context of the transaction is.
There is no concept of full privacy, and therefore no magic mixin enabling full privacy.
The default mixin is 4 in monero-wallet-cli, and the network will enforce a minimim of 2, except for particular circumstances in which an input can't be mixed. See https://lab.getmonero.org/pubs/MRL-0004.pdf for a discussion of how the minimum mixin can prevent chain reactions in determining the real input in a ring.
Now, the higher the mixin, the more possible inputs are used aside from the one that's actually spent, and higher mixins are encouraged for increased privacy. There just isn't a threshold at which your privacy becomes "full". Even if you were to mix against every single other output on the chain, you would still not have full privacy.
There is no mixin amount that gives you "full" privacy. The minimum mixin of 2 gives the smallest amount of plausible deniability possible (1 in 3), and the default of 4 is a little bit better (1 in 5). The importance of each additional mixin decreases for each additional one. For example, a change from "1 in 10" to "1 in 11" is less meaningful than a change from "1 in 5" to "1 in 6". The defaults are good for the vast majority of transactions.
In general, the higher the mixin count, the more plausible deniability and the more private it will be. I want to address a few caveats to this general rule:
Do not use an odd, recognizable mixin for all of your transactions. If you arbitrarly choose the number 299 for all your transactions, it will be easy to spot you by searching for mixins of that size on the blockchain. A more common mixin of 10 may actually provide more anonymity because you won't stand out as much.
Monero's 0.10.0 code includes RingCT to hide transaction amounts, but RingCT will not be fully implemented until the next hard fork release scheduled on approximately 5 January 2017. This means that even with a high mixin, you should be aware of all the ways your transactions can be determined by analyzing transaction amounts. RingCT is now implemented. Please make sure to sweep unmixable if you received transactions before the RingCT date.
Your IP address is still being broadcast to the world if you run a node (which you should do). If you only turn on your node to make a transaction before turning it off again, then people can pick up a pattern of what transactions you made. Kovri will eventually hide your IP with I2P, but even with Kovri, it is highly recommended to run your node 100% of the time.
I think user36303 gave an adequate answer that addressed your concern, but I want to tack on an additional point that is unrelated to his answer.
The question implies that mixin is the determining factor for privacy. There are two implementations coming that will also address privacy as it relates to sending transactions.
RingCT, already in the code, and enacted (wrong word?) in December 2016, will make it so that inputs aren't visible at all, so the mixin becomes less important.
Kovri will allow for broadcasting transactions over I2P, so senders will be "protected" from those who are monitoring their IP for Monero transactions.