How many records would you expect to be returned by this: where uid=@uid

Is it one (or a few) or large numbers? The query itself as posted is very simple. Assuming a clustered index on the uid column and a small data set, you should be seeing a seek running fairly quickly. If it's a nonclustered index on uid, then you'd still see a seek if it's only a few rows combined with a key lookup or rid lookup. However, if there is no index on uid or it's returning a bunch of rows, then you're going to see a scan. If it's a bunch of rows, there may not be much that can be done to help. If it's just a missing or incorrect index, that can be fixed.

Also, it could just be network latency if you're testing the retrieval from Azure from your client and your client is not also running in Azure (by the way, that counts as data egress and will cost money).

We're working off of a very limited set of data here (the query). Getting the table structure, including indexes, keys, constraints, and an execution plan (preferably the "actual" plan), would make a big difference. Assuming you're on SQL Server 2016 SP1 or greater, the actual plan of the execution plan will have the run time query performance included in the plan, so you won't have to capture the query metrics separately.