Listen to those two jgreco and cyberjock. They know what they're talking about.
As jgreco pointed out, ZFS uses a ZIL whether its on the disks or on SSDs. A SLOG is just a a seperate ZIL. As far as a SLOG making a pool slightly less fragmented; I've never heard of that, I'd say don't worry about it.
The internet is plagued with ZFS, SLOG, L2ARC copypasta, so I'll continue...
if that fails then your pool will definitely fail as well.
No. The consistency of the application data may be compromised, but the pool will not fail. As stated, yes it is a log of synchronous transactions. Though, in normal operation data never flows "through" the SLOG. Data is only read from the SLOG on the next import after a power failure. Therefore, if your SLOG fails catastrophically during regular operation, your pool will not. ZFS will learn the device is'nt accepting writes anymore and mark the pool as degraded. If your SLOG fails during or right after a power failure, you will lose whatever data is in the SLOG, but your pool will certainly not "definitely fail as well". If the SLOG is mirrored as it should be, ZFS will figure which mirror device holds the correct data.
risks of using this approach
If you implement a SLOG incorrectly, it will be no safer than simply setting "sync=disabled" pool wide. Correct implementation means mirrors of capacitor or battery backed flash. These are not suggestions, these are functional requirements. That said, you do it right, yeah you'll be pretty safe, and benefit from the performance of SSDs for synchronous writes.
Why would you want to use synchronous transactions in the first place though? What is the goal here?
Synchronous writes exist because they are your most important data. Otherwise an application has no guarantee of consistency. Databases issue a lot of synchronous writes.
freebsdinator , since you are running a database, I absolutely advise you to use a mirrored SLOG. This is a good application for the feature.