How to reclaim database space on Azure SQL Server after setting nvarchar values to null There is db space challenge at hand on Azure SQL Server database. 490 GB out of 500 GB is used. That's what I read from nice pie chart on Azure portal.
Notice that some of the techniques used on-prem won't work for Azure SQL Server Database.

Biggest table is DidbStudySerumLevelDeviation.

exec sp_spaceused 'RulesEngine.DidbStudySerumLevelDeviation '

returns

+------------+------------------------------+
| name       | DidbStudySerumLevelDeviation |
| rows       | 20 805 409                   |
| reserved   | 133 332 840 KB               |
| data       | 123 079 792 KB               |
| index_size | 9 772 192 KB                 |
| unused     | 480 856 KB                   |
+------------+------------------------------+


Table definition: 

CREATE TABLE [RulesEngine].[DidbStudySerumLevelDeviation](
    [Id] [uniqueidentifier] NOT NULL,
    [PatientTherapyId] [uniqueidentifier] NOT NULL,
    ...
    [Abstract] [nvarchar](max) NULL,
    ...
 CONSTRAINT [PK_RulesEngine.DidbStudySerumLevelDeviation] PRIMARY KEY CLUSTERED 
(
    [Id] ASC,
    [PatientTherapyId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

Clustered index exists on primary key. There are also some nonclustered indexes.
Abstract column data takes around 90% of space of a table. 

Procedure is run to set unnecessary Abstract column data to null. That should reduce problematic column "weight" to 10%. However this doesn't reduce database size. How to reclaim that database space?

Maybe I should wait and some Azure SLQ maintenance magic occurs? It sounds like wishfull thinking though.

Regarding possible duplicate

Answer to this question might me specific to Azure deployment of SQL Server. Drop in database size reported in Azure portal or read from exec sp_spaceused didn't change.
Please defrag all indexes. As mentioned on this article, fragmentation can claim a lot space.

Run sp_helpfile to verify the log is not consuming space also. If the log is big run the following statement to recover space.  

DBCC SHRINKFILE (log, 0)


On this thread I provided some queries that may be useful about database size.

Hope this helps.