I used Atlassian JIRA for bug and issue tracking at my last job. I absolutely loved it and it was particularly easy on the eyes.
My present company is using Trac instead, and while it does do all the basics, I am finding it really lacking, particularly with the inability to easily setup multiple projects and link issues.
Oh, and the fact that it uses SQLLite is a bit of an issue for me to.
Does anyone have any other good reasons to switch?
Cost is probably the single biggest reason.
JIRA is great but unless you are open source, the licensing fees are prohibitively expensive for small projects.
Trac is free and although personally I think it feels a little out dated, it seems to work for people.
Having used Trac at my last job and Jira at my current job, I must say that both have their merits. Jira is a lot mote featureful, like linking issues, tracking time spent, having multiple projects with permissions and linking between them. On the other hand if those features aren't important, Trac has a much easier to use UI, and the integration between the issue tracker, wiki and SVN browser (which beats the socks off of Fisheye in my view), along with the integrated timeline view makes for a pretty neat user experience. The ticket query interface is especially neat. This is ofcourse very much a matter of taste and familiarity.
Alltogether, Trac is much better suited for open-source type of projects, but the features of Jira are most likely worth the cost and the cluttered UI if you are a commercial development house.
As for Sqlite, Trac works fine with Postgres.
I have used Trac for several years already. First of all, the sqlite issue... You can easily switch to MySQL if You like to. We began to feel a bit of a laggy about the interface when the wiki table exceeded 1 million rows (a rouge script did that), so I guess You should be fine about performance with Trac. You can also use multiple nodes serving Trac, if that will be a problem (it's good to have 2 in case of a power/network failure anyway).
If Your team has only 6 coders, You could consider putting all projects in a single Trac project and using the ticket's component or milestone fields. It should work just fine.
It is also worth to note that Trac is extremely extensible through plugins that can be easily obtained from Web.
I have no Trac link issues whatsoever so I can't comment on this problem. Could You be more descriptive?
And about the inability to easily setup multiple projects... Our admins wrote a ~100 lines script that handles it and now it's like 5 minutes to set up a new Trac project. We have like 60 of them already. I don't know about Jira, but new projects are being set up rarely. You will want to create a report through a ticket query quite more often.
If You consider commercial solution, take a look at FogBugz - I've heard it's amazing... However it's not as extensible as Trac (You can't just use the rich python api to add a functionality You need - and I value this feature very high in Trac).
Take a look on a length of Trac plugin list. You can easily install any of them if You like to.
I've just stumbled across Redmine which sounds like something which could work well for a team of about 6.
If by multiple projects you mean multiple subversion repositories, Trac version 0.12 supports this. Until now I have been using Trac on mod_wsgi which allows you to serve all your trac instances from one mod_wsgi instance, and show a list of all the tracs you have at a certain url with links to them. This was very simple to set up. We've also scripted trac project creation along with subversion repository creation so thats a 1 line command for us now.
The usability of the GUI is most important for me. Since trac-plugins exist for everything a programmer loves, both get the job done. It is essential that the user has fun using his bugtracking tool, since the process-loaden activity is not the most appreciated anyway.
Setting my custom filters anywhere in the wiki is awesome in trac.