Any database exposure vulnerability that does not compromise the host is fully mitigated by client side encryption. This is a very large class of vulnerabilities in the real world, so this is actually a very good case in favor of client side encryption.
Losing the database is game over. The odds are very high that by losing the database loses command execution on the server.
Thomas is right, though: if you lose the DB, you're forked.
(btw I don't mean that command execution is not a problem, I mean that if you configure your sql server well it should not allow command execution, there's not _that_ many ways to escape the database..)
Um, I don't think so. Client side JS is very good at doing SQLi. How on earth does client-side encryption mitigate against SQLi?
If your site is entirely self-contained and transported in full over https with a trustable ssl certificate and your users are using reasonably secure passwords and run browsers with addons that respect the confidentiality of https communication then client-side js encryption might be a nice extra layer of data protection.
It won't protect against the government probing, and it won't protect against a passionate lulz hacker.
The government can always subpoena the host website, and force it to fetch the password from the user, thereby comprimising their data. The government also has access to ssl certificates so it could even do this without notifying the host website. You may assume that lulz hackers have similar capabilities.
If you think about it straight, the only way this can be truly secure is with a browser extension that digitally signs and versions _all_ javascript on a website, and the signing is done by a fully trusted third party (which arguably don't exist).