I am assuming you are not a database expert but basing this on the look and organization of the code and not the data structures and design. If that is not true than please share your findings instead of teasing us.

I'm curious would you do the same with your editor (or IDE)? You should see the source code for those behemoths (with the exception of the rewrites like nvim) they are pretty nasty.

Are you going to pick a different editor just because Vim or Emacs (or whatever editor) has nasty code?

Guess what IDE has pretty clean code and is extremely modularized... Eclipse. I can tell you Eclipse is not a comfortable editor (and I use it all the time because I'm used to it not because the code is elegant).

Mature projects often have pretty ugly code but they are mature and stable. Ugly code also doesn't necessarily mean poor design (e.g. if your editor is single threaded and has nice looking code its still single threaded).

I wouldn't imagine it being controversial to prefer well engineered code over less so for bits you will need to depend on.

I would much rather choose a battle tested database that has the features I want, performs well to my testing and profiling than "familiar" looking code. Because good looking code is really more often or not familiar looking code.

So unless the OP is an expert I believe basing the most critical aspect of your application just because the code isn't to your liking is sort of asinine.

Also vim is not flaky. The insides may be a nightmare, but it's very solid.

Mysql and PostgreSQL offer similar functionality, people use both systems for similar tasks. When you try to decide between the two, you find conflicting arguments all over the web. I think in such case looking at the quality of code can be a key signal to help you make a good decision.

I do agree that projects with ugly code can still be extremely useful and in many case an optimal choice, but such project will more likely become obsolete quicker and will cause problems more often than project with high quality code.

It would be pretty low on my check list. The number one for me would be profiling and testing the databases. IMO you should do that first. Even the ability to extend the database with plugins would be higher on my list than code quality (this is for a database). Probably 10 other things would be higher on my list than code quality (again for databases... for libraries thats a different story).

Looking over code would give you more than just an impression of its style; it would also give you a feel for the quality of the product. If most of the code you look at is of poor quality, it is very unlikely that the product, at a high level, will be any better.

So you are going to base the crashing of a database on the cursory non expert runtime of your eyes. Why not just test the database, read the doc, ask other experts.

Secondly rarely do most developers extend their database so their is very little need to know that codebase and they probably should not change that codebase (given the criticalness).

You know what developers extend often... their editors and IDEs. The code quality (in terms of readability) of that should be much higher.

Now obviously if you have nothing but the code to base (like no doc, no benchmarking, no existing mind share, etc...) and are generally knowledgeable in the area than yes code quality would be a good decision criteria but I remind you the OP said it was the major reason between Postgres and MySQL which are probably written by superior experts than the OP.

You look over the source code to decide whether the database is worth proceeding with. I would assume the OP did other research as well, even if code quality was the deciding factor.

And again, I don't find the text editor analogy a compelling argument.

I would say his comment implied he went with Postgres. I generally think of MySQL, which, if memory serves, was started by people with little database knowledge, as not being as high quality as Postgres, which came directly out of another relational database project.