Microsoft SQL Express offers so much when evaluating a persistence store for your own applications, especially if you are targeting Windows and utilising the .Net framework.
SQL Express offers pretty much most of the common features available in the full blown SQL Server which makes development and switching between SQL Server and SQL Express pretty seamless. However, there is one major factor which I would reccomend you consider… Deployment. You would expect the deployment of SQL Express to be as easy as installing say the .Net framework, which you will no doubt have to distribute.
In fact if you are targeting an internal business project or something with a fairly small consistant machine image (e.g. same operating system version) then you may not have too many problems, hey you can even set it as a pre-requisite to install along with the .Net framework as part of your visual studio deployment project.
Message Queues are a great tool for interprocess communication if you need to ensure that a message is processed, regardless of the target process’s connectivity or runtime state. If you are developing with Microsoft’s .Net Framework you can take advantage of Windows Communication Foundations built-in support for Microsoft Message Queues.
I have been using WCF with Microsoft Message Queues on a recent project, which as part of a back-end processor, the queues are automatically created in the event that they do not exist. The queues can be programmatically created using the following code (C#):
When you deploy this application to a Windows Server 2008 machine, the queue will be created as expected and as default allow messages to be inserted into the queue. However Windows Server 2008 R2 behaves a little differently, as default the queue will not allow anyone other than the owner to insert messages into the queue.