From a management perspective Azure SQL DB and Azure Elastic Pools are the same. As far as the DBA or the developer is concerned they are the same. Think of Elastic Pools as a billing construct. With SQL DB (not in Pools) you pay for X amount of performance for each database. With Elastic Pools you pay for D performance for E databases and each database gets at most F performance.
So lets say I buy a Standard Elastic Pool with 800 eDTUs. I can put up to 500 databases in there and they are going to share that 800 eDTUs. Each database can have up to 100 eDTUs per database before it’s going to have it’s performance throttled.
The idea behind the elastic pools is that the performance profile for each database will be different, and they won’t need to spike to their limit all at the same time. If they did that would be a performance problem as you’re run out of DTUs to spread across the databases. In this example pool basically 8 databases can hit 100% of their DTU limit before everyone suffers.
The reason that you’d want to setup things this way is from a pricing perspective. An 800 eDTU pool is going to cost you ~$1800 a month. A single 100 DTU standard database will cost you ~$150 a month. If you have more than 12 databases that all need to cap out at 100 DTUs, and their performance profiles aren’t the same (the have their spikes in workload at different times) then putting them in an elastic pool will be cheaper.
From a management perspective databases in a SQL DB and outside a SQL DB are basically the same. Everything that’s supported inside a normal SQL DB is supported inside an Elastic Pool database. They have the same features and limits. The big difference is that the performance limits are now a shared pool of resources not dedicated per database.
For DBAs who are used to working with instances on-prem this should be a familiar pattern for you. Think of an Elastic Pool as a SQL Instance on a server. The server is a pool of resources that you have to decide what databases to stick inside that pool. It’s the same idea here. The difference between on-prem and in Elastic Pools is that in Azure you don’t know how many cores or RAM you have, you just have the eDTU construct. And you can have multiple Elastic Pools per Azure SQL Server name (something.database.windows.net).
For monitoring you have the same options between Azure SQL DB and Elastic Pools. You can use the Azure portal, you can query the API using PowerShell or the CLI. Or you can use DB Sentry from SentryOne (SQL Sentry) to monitor things just like you used to.