Database Pools on SQL Azure, although not completely released, are rapidly gaining adoption in the market. The technology is solid, and I would guess that the core functionality is not even new. Primarily, it is a new pricing and load balancing model, allowing database applications to take financial advantage in the ebb and flow of database utilization.
In summary, you create a database pool of your own, based on the size and performance you want to experience. Then you load as many databases as make sense to you into the pool. SQL Azure then manages the pool as a whole, instead of simply as a single database. You determine how much computing power and disk allocation you want to make available in your pool. SQL Azure handles the allocation of those resources across all the database activities within that pool.
If your utilization changes, or you begin to have multiple databases experiencing peak loads at the same time, you can increase (within the available limits of SQL Azure) the pool capabilities based on the pricing tiers available.
It appears that the capacity and pricing are similar to that for a single database. In other words, the largest pool size is 750gb, with the largest database size of 500gb. So, if you have a lot of large databases that are not constantly active, then you cannot necessarily combine them into a single pool, unless the size of all the databases is under 750gb. If you grow beyond your max pool size, all of the databases become read only.
Microsoft has really done a great thing for this pricing model. How many server resources spin idle waiting for someone to make a request. This implementation allows the sharing of resources for databases, while providing ease of elastic sizing on demand. I can see a company, with a lot of departmental databases for special interest needs, greatly reducing their Cost of Ownership with this resource pooling model. We have been taking advantage of it in the core SQL Azure capabilities, by sharing pools with other companies. Now we can create and manage our own shared resources, and reap the benefit of intermittent database access, at a lower cost.