If I'm using a framework, which escapes the input when storing in DB and XSS Cleans the output automatically (allowing only a few tags) when used correctly,
Is it safe to just store content created by WYSIWYG editors such as CKEditor and then display them on the website? or it's better to use some kind of Markdown language?
Using a different markup (eg. Markdown) for storing html entered by the user is a can of worms. A lot of complexity, and would not automatically solve your issues (which is mostly XSS). You can just store sanitized used input (or even the original unsanitized user input if you like, see below).
The point is, at some point before adding user input to the page DOM, you need to remove Javascript. As these editors tend to have a preview feature that does not send data to the server at all, it's usually best to remove javascript on the client side, in javascript, via hooks your editor provides. In case of CKEditor one such hook appears to be the contentPreview event (I'm not very familiar with CKEditor though).
So you should have a javascript library that takes a bunch of html code (the output of your editor), and returns the same html, but with any Javascript removed. Google Caja has such a client-side html sanitizer component, and also there are other such libraries as well. This should be run upon (before) preview, so all javascript is removed before actually viewing content. The same should also be done before displaying content received from the server (regardless of storing sanitized or unsanitized data).
Whether you want to do this sanitization before sending data to the server depends on your usecase. You don't strictly need to, but then you have to be careful how you use that data in other potential applications (like for example another "admin" or "management" application might display it in an unsecure way - this should not be the case as this would be an XSS in the other application).
Also note that even with all javascript removed, html input by a user might still present other potential vulnerabilities. For example being able to embed an image with a source pointing to another site might alolw an attacker to track usage of an application page. Being able to link to external sites might allow an attacker to perform phishing attacks, and so on. This depends on your exact usecase and threat model, and none of this will be prevented by sanitization only.