I think you may have better luck with a question like this on a CQRS forum, since this may require more of a back-and-forth discussion. Plus the real answer is probably "it depends".
That said, it sounds like you are mixing the "strict" definition of CQRS with more of the "accepted" definition of the pattern. The former is merely a separation of the read logic and write logic (and their structures). The latter is usually defined as having a highly denormalized read model and usually involves some form of event driven architecture (including event sourcing is some cases).
It sounds like you have something of a mix of these two ideas. My first question would be: what are your event handlers doing if they're not creating denormalized read models? Are they just notifying subscribers to invalidate cache and refetch data?
But bottom line, I think your instinct is correct--the event is published after the data has successfully been updated. If one handler's responsibility is to update the (command/write side) database, other subscribers have already been notified that this happened which may not be true if the update to the database fails.
So your command side should update the database, and your reads should be querying your normalized data store and projecting the results onto denormalized result sets. Again, events (if used at all) would probably just be used for notification that data has been updated, and that subscribers may need to requery (again, like cache invalidation).