I don't know about the latest version of PHP if that's what you're using, but most frameworks now handle connection pooling behind the scenes so I'd first check to ensure that it's not already being done for you.
Now, personally, I would not apply a singleton pattern to your DB connection manager or whatever it is you're creating. First, if something screws up for one user, it screws up for everyone, unless you have some graceful way of dealing with the singleton instance's exceptions. Maybe this is irrelevant in your situation, depending on complexity, but philosophically I'd want to keep things separate and just instantiate a new class as needed.
I would also ask: do you actually NEED a singleton DB object? What does the application of this pattern to DB connections give you? The singleton, like most GOF design patterns, is really the providence of an application, not a DB. If fact, there's a well known phenomenon called impedance mismatch (
http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch which occurs when you try to apply OOP design principles to a relational DB. This is more relevant if by "database class" you mean a class that represents a table in the DB, but still applies in this case where the pattern doesn't appear to give you anything valuable, and potentially opens you up for some obscure errors should things go wrong.
As for multiple DB connections, on a number of cases I've worked with applications that aggregate data from a wide variety of sources, including several different databases instances AND several different database applications. I'm guessing this is beside the point for your situation, but it's certainly quite commonly done in the industry.
