It's hard to say without a complete understanding of what you are trying to accomplish but based on what you are saying, I think a database makes more sense. You might want to use a database and a queuing system together.
The reason is that in this kind of situation you generally want to have some sort of audit-balance-control capability and queues won't provide this. You are going to want to know who did what when right? Where are you going to track that? Most likely it's in a DB. Also you need to worry about things like a worker selecting a task and then going home sick. You don't want to have a bunch of long-term uncommitted reads on the queues.
The important thing to understand about queues is that reads are destructive. This makes them a poor solution (by themselves) in a lot of common situations. In a nutshell, once someone has committed the read, it's difficult to impossible to know that the message was ever there. If a message gets read and committed by a consumer but that consumer fails to process it successfully, things can get lost. A lot of queuing systems have "guaranteed delivery" which doesn't mean as much as people think it does. It simply means it got to it's destination (or was reported as undeliverable) but it doesn't guarantee that the consumer did anything with it. "So what, reading from a database doesn't change that" you might say. The difference is that when you read the message from the DB, it doesn't disappear. Often you won't even want to delete it from the DB but rather track the status. This means you don't lose messages due to flaws in the consumers.
I think the hybrid solution works well here. Use queues as a distribution mechanism. They are great for handling lots of readers pulling from the same set of things and making sure only one reader gets each thing. You can do that in DBs but it's kind of ugly. Then once a reader has claimed and item, it's can update the DB with that info with very little contention. You can send the same message on the queue as needed for your 2-worker requirment (you'll need a mechanism to avoid the same worker handling both requests) and also in the case a worker pulls a message but never does the task.