so I'm working on a website project with the goal of writing my own blog posts with markdown syntax.
Why? What's wrong with the existent solutions?
I plan on storing this in my MSSQL database. (related question) Do you agree that this is the best way of handling it?
I wouldn't agree that this is the best way. It is one of the ways to do it. For my blog, I used MongoDB. It is neither a better, nor a worse choice.
I'd like to download images references in the markdown onto my server to guarantee the availability once used in a post. I plan on storing these on the servers filesystem with an updated reference in the markdown (related question). This requires me to parse/extract the markdown to find the relevant usages, how would you do this? Would you even bother to do this?
There are a lot of issues with that:
You shouldn't be covertly modifying the original post. You can use the technique used at Stack Exchange where the user can upload images, but modifying the original Markdown without the consent of the user is both risky (you can unintentionally screw up with the post) and misleading (as a user, I would be highly surprised to see all my links replaced by something else under the hood).
You open your site to potential attacks (if you are not the only one who can post articles). What if the image is not an image, but a malicious script that you'll save to your server? Or what if the image is 5 GB large, making a DOS attack extremely simple to perform?
You make it possible to use your site to attack other sites (if you are not the only one who can post articles). Imagine a script posting, again and again, a message containing a few thousand links to images from a given server. You will be now the one performing a DOS attack on the server hosting the images.
There may be legal issues as well. If an image is copyrighted and you clone it to your server, you may be in a big trouble.
Images are the thing which makes a heavy use of the bandwidth. Why would you pay extra bandwidth for that, instead of letting other servers do it?
A potential benefit I see with this is the ability to log/track the access of those images
Why would you care about that? You already have the statistics for a given article. Google Analytics will give you even more information about the users.
Would you process/convert the markdown every time a user opens the page?
The same Markdown always produces the same HTML. Therefore, there is no need to generate it again and again every time someone visits the page.
Store HTML side by side. Update it when Markdown is modified.
If, for some reason, it's easier to generate HTML when a page is shown, then at least make sure you rely on aggressive caching.
By the way, if you are not the only one who can post articles, letting the generation of HTML happen during the page load makes it easy to perform a DOS attack. A malicious Markdown (i.e. specifically crafted so that the conversion to HTML would take a long time) could be injected, and then, the attacker would simply call in a loop the page showing the article.
I thought about writing my own markdown processor to get more flexibility, I'm not sure how smart this is.
Not smart. Markdown is relatively complex to parse, and you will introduce bugs. Those bugs could then be exploited to hack your server.
The existent implementations of Markdown to HTML conversions are relatively stable and many of them were reviewed by a lot of persons. Unless your project is specifically to create a competing converter, just use the existent ones.
Also, how would one apply custom styling to it (e.g. for code snippets?) and so forth.
Some Markdown to HTML converters can be customized to enable the use of custom tags.
Also, don't forget that HTML elements can be put within Markdown.
Are there any potential downsides to having an editor like that?
One of the issues is that you'll have two Markdown to HTML converters: a server-side one used to generate the HTML which will be displayed later to the readers, and a client-side one which will show contents to the writer of a blog post. Maintaining both is not particularly difficult, but it still requires additional work. Some features which are available in one may not be available in the other.
You can of course use only one converter by making AJAX requests to the server every time the article is modified. However, this you need to be careful to avoid doing a request at every character typed: for long or slightly esoteric articles, it will use a lot of resources and bandwidth.