Azure SQL Query Editor: What Can You Do Directly From the Azure Portal Now?

Developers often need to run a quick SQL query while troubleshooting an application, checking production data, or validating a database change.

The problem is usually not writing the query.

The problem is getting connected.

You may need SSMS, Azure Data Studio, a database client, VPN access, firewall configuration, credentials, and the correct server details before you can run a simple SELECT.

Azure SQL Query Editor provides a browser-based alternative for supported Azure SQL resources. It lets developers connect to a database directly from the Azure portal and execute T-SQL without installing a separate database client.

That makes it useful for quick investigation and administration, but it should not automatically replace a full database development environment.

The important question is: what can you realistically do with Query Editor, and where should you still use SSMS or another dedicated tool?

What Is Azure SQL Query Editor?

Azure SQL Query Editor is a web-based SQL interface available from the Azure portal.

The basic workflow is:

Azure Portal
     |
     v
Azure SQL Resource
     |
     v
Query Editor
     |
     v
Database Connection
     |
     v
T-SQL
     |
     v
Query Results

Instead of opening a separate desktop application, you can work with the database from the browser.

This is particularly convenient when you are already investigating an Azure resource and need to verify something in the database.

A typical workflow might be:

Application Issue
       |
       v
Azure Portal
       |
       v
SQL Database
       |
       v
Query Editor
       |
       v
Check Data

For simple diagnostic tasks, that can save time.

Opening Query Editor

The exact portal experience can change as Azure services evolve, but the general process is straightforward.

Open the Azure portal and navigate to the supported Azure SQL resource.

From the resource interface, open Query editor.

You will then be prompted to authenticate.

Depending on the supported authentication configuration, you can sign in using Microsoft Entra authentication or database authentication.

Once authentication succeeds, Query Editor provides a SQL workspace where you can enter and execute T-SQL.

Authentication Comes First

A browser-based SQL editor does not bypass database security.

You still need a valid identity with appropriate permissions.

A simplified architecture looks like this:

Developer
    |
    v
Azure Portal
    |
    v
Query Editor
    |
    v
Authentication
    |
    v
Azure SQL Database

The database continues to enforce its normal authorization rules.

This is important when troubleshooting access issues.

If your account cannot read a table through a normal database connection, Query Editor should not be treated as a way around that restriction.

Running a Basic SELECT Query

Once connected, you can run normal T-SQL queries.

For example:

SELECT TOP (20)
    Id,
    Name,
    Status
FROM dbo.Customers
ORDER BY Id DESC;

The result appears directly in the browser.

This is useful for quick checks such as:

• Does a record exist?

• What is the current status?

• When was a row last updated?

• Did a migration populate the expected values?

• Are recent records being inserted?

A simple query can often answer these questions without opening another application.

Filtering Data

You can use normal SQL filtering.

SELECT
    Id,
    Name,
    Status,
    CreatedAt
FROM dbo.Customers
WHERE Status = 'Active'
ORDER BY CreatedAt DESC;

For troubleshooting, it is usually better to narrow the result set.

Instead of:

SELECT *
FROM dbo.Customers;

use:

SELECT TOP (50)
    Id,
    Name,
    Status
FROM dbo.Customers
WHERE Status = 'Active';

This makes the query easier to review and reduces unnecessary data retrieval.

Checking Application Data

One of the most useful Query Editor scenarios is application troubleshooting.

Imagine an API reports:

Customer order could not be processed.

You can inspect the database directly:

SELECT
    OrderId,
    CustomerId,
    Status,
    CreatedAt,
    UpdatedAt
FROM dbo.Orders
WHERE OrderId = 10582;

Then check related records:

SELECT
    PaymentId,
    OrderId,
    Status,
    FailureReason
FROM dbo.Payments
WHERE OrderId = 10582;

This gives the developer a database-level view of what happened.

The application logs may say that an order failed.

The database may show why.

Joining Tables

Query Editor is not limited to single-table queries.

You can use joins just as you would from SSMS or another SQL client.

SELECT
    o.OrderId,
    c.Name AS CustomerName,
    o.Status,
    o.CreatedAt
FROM dbo.Orders AS o
INNER JOIN dbo.Customers AS c
    ON c.Id = o.CustomerId
WHERE o.Status = 'Pending'
ORDER BY o.CreatedAt DESC;

This is useful when troubleshooting business workflows where the relevant information is distributed across multiple tables.

For example:

Customer
   |
   v
Order
   |
   v
Payment
   |
   v
Shipment

A single query can help reconstruct the current state.

Aggregation and Operational Checks

Query Editor can also be used for quick operational reporting.

For example:

SELECT
    Status,
    COUNT(*) AS TotalOrders
FROM dbo.Orders
GROUP BY Status
ORDER BY TotalOrders DESC;

You might get:

Status       TotalOrders
-----------  -----------
Completed    18240
Pending       1240
Failed         182
Cancelled       94

This can immediately tell you whether a reported problem is isolated or affecting a larger number of records.

Another useful check is the most recent activity:

SELECT TOP (20)
    OrderId,
    Status,
    UpdatedAt
FROM dbo.Orders
ORDER BY UpdatedAt DESC;

INSERT, UPDATE, and DELETE

Query Editor is not necessarily limited to read-only queries.

If your authenticated database identity has the appropriate permissions, you can execute data modification statements.

For example:

UPDATE dbo.Customers
SET Status = 'Inactive'
WHERE Id = 10025;

Or:

INSERT INTO dbo.AuditEvents
(
    EventType,
    Description,
    CreatedAt
)
VALUES
(
    'ManualCheck',
    'Checked customer account from Azure portal',
    SYSUTCDATETIME()
);

And:

DELETE FROM dbo.TestRecords
WHERE IsTestData = 1;

This is where caution becomes important.

A browser-based SQL editor makes database access easier.

It does not make dangerous SQL safer.

Always Verify Before Updating

For manual database changes, use a two-step process.

First identify the rows:

SELECT
    Id,
    Status
FROM dbo.Customers
WHERE Id = 10025;

Then perform the change:

UPDATE dbo.Customers
SET Status = 'Inactive'
WHERE Id = 10025;

For a larger update, verify the affected row count before executing it.

A particularly dangerous mistake is running:

UPDATE dbo.Customers
SET Status = 'Inactive';

when the intention was to update one customer.

The same principle applies to DELETE.

Always make the WHERE condition explicit.

Transactions for Risky Changes

For more complicated manual changes, use a transaction where appropriate.

BEGIN TRANSACTION;

UPDATE dbo.Orders
SET Status = 'Cancelled'
WHERE OrderId = 10582;

SELECT
    OrderId,
    Status
FROM dbo.Orders
WHERE OrderId = 10582;

-- COMMIT TRANSACTION;
-- ROLLBACK TRANSACTION;

During an investigation, you can verify the result before committing.

Do not blindly execute transaction scripts in production without understanding locking, transaction duration, and application impact.

Creating Temporary Troubleshooting Queries

Query Editor is particularly useful when investigating a problem that does not justify creating a permanent script.

For example:

DECLARE @CustomerId INT = 10025;

SELECT
    c.Id,
    c.Name,
    c.Status,
    o.OrderId,
    o.Status AS OrderStatus
FROM dbo.Customers AS c
LEFT JOIN dbo.Orders AS o
    ON o.CustomerId = c.Id
WHERE c.Id = @CustomerId;

You can change the variable and rerun the query.

This is convenient for one-off diagnostics.

For frequently repeated operational tasks, however, store the query in source control rather than relying on browser history.

Checking Schema Information

Query Editor can also be useful for understanding database structure.

For example:

SELECT
    TABLE_SCHEMA,
    TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
ORDER BY TABLE_SCHEMA, TABLE_NAME;

You can inspect columns:

SELECT
    COLUMN_NAME,
    DATA_TYPE,
    IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'dbo'
  AND TABLE_NAME = 'Orders'
ORDER BY ORDINAL_POSITION;

This can help when working with an unfamiliar database.

For detailed database development and administration, though, a dedicated tool still provides a richer experience.

Stored Procedures

If your database contains stored procedures, Query Editor can be useful for executing them.

For example:

EXEC dbo.GetCustomerOrders
    @CustomerId = 10025;

You can also inspect procedure definitions where your permissions allow it.

SELECT
    OBJECT_SCHEMA_NAME(object_id) AS SchemaName,
    OBJECT_NAME(object_id) AS ObjectName,
    definition
FROM sys.sql_modules
WHERE object_id = OBJECT_ID('dbo.GetCustomerOrders');

This can be helpful during troubleshooting when you need to understand what database-side logic is involved.

Querying Azure SQL From a Production Environment

The biggest benefit of Query Editor can also become its biggest risk.

The database is accessible from a browser.

That means a developer can quickly investigate a production issue.

It also means a poorly written query can be executed against production just as quickly.

Use a clear environment strategy:

Development
     |
     v
Testing
     |
     v
Staging
     |
     v
Production

Permissions should become progressively more restrictive as the environment becomes more critical.

For production:

Read Access
    |
    +-- Diagnostics
    +-- Verification
    +-- Investigation

Write Access
    |
    +-- Restricted
    +-- Audited
    +-- Explicitly Approved

Do not give every developer unrestricted production write access simply because Query Editor is available.

Query Editor vs SSMS

Query Editor and SSMS serve different purposes.

If you need to quickly inspect a record, Query Editor is convenient.

If you are designing database objects, managing complex SQL Server environments, or doing advanced administration, SSMS remains the more complete tool.

Query Editor vs Azure Data Studio

Azure Data Studio historically provided a lightweight cross-platform database development experience.

For teams working with Azure SQL, the broader question is now which Microsoft database tooling fits the workflow and current product direction.

A browser editor is useful when:

No Installation
      +
Fast Access
      +
Azure Portal Context

is more important than advanced local tooling.

Common Mistakes

Running SELECT * on Large Tables

Avoid:

SELECT *
FROM dbo.Orders;

Use:

SELECT TOP (100)
    OrderId,
    CustomerId,
    Status
FROM dbo.Orders;

Running UPDATE Without a WHERE Clause

This is one of the easiest ways to damage production data.

Always verify the target rows first.

Assuming Browser Access Means No Network Restrictions

Authentication and network configuration still matter.

If the database cannot be reached because of networking or firewall configuration, Query Editor does not automatically remove those controls.

Testing Destructive Queries Directly in Production

Test the query against a non-production database first.

Copying Sensitive Data Into Tickets or Chat

Query results can contain customer information, tokens, emails, financial records, or other sensitive values.

Do not copy database output into external systems unless the organization's data-handling policy allows it.

Troubleshooting

Query Editor Does Not Connect

Check:

1. Database availability.

2. Authentication method.

3. User permissions.

4. Network configuration.

5. Azure SQL firewall settings where applicable.

6. Whether the selected database is the intended database.

Login Works but Queries Fail

Authentication and authorization are different.

You may successfully connect while still lacking permission to read a specific table.

For example, a user may have access to:

dbo.Customers

but not:

dbo.Payments

Check database permissions before assuming the editor is malfunctioning.

Query Times Out

Start by simplifying the query.

For example:

SELECT TOP (10)
    Id
FROM dbo.LargeTable;

Then gradually add:

• Filters

• Joins

• Aggregations

• Ordering

This helps identify which part of the query causes the problem.

Results Are Empty

Verify:

SELECT COUNT(*)
FROM dbo.Orders;

Then check the filter:

SELECT TOP (20)
    Status
FROM dbo.Orders;

A query returning zero rows does not necessarily mean the database is empty. The filter may simply be incorrect.

Best Practices

1. Use Query Editor primarily for quick investigation and controlled database work.

2. Use least-privilege database permissions.

3. Prefer read-only access for routine production troubleshooting.

4. Always test UPDATE and DELETE conditions with SELECT first.

5. Use TOP when exploring large tables.

6. Select only the columns you need.

7. Avoid copying sensitive query results into external tools.

8. Keep important operational queries in source control.

9. Use transactions carefully for manual changes.

10. Test destructive queries against non-production data first.

11. Monitor long-running queries and database resource consumption.

12. Use SSMS or another full-featured tool when the task requires advanced database administration.

When Should You Use Azure SQL Query Editor?

Query Editor is a strong choice when you need to:

• Quickly inspect application data.

• Validate a database deployment.

• Check whether a record exists.

• Investigate an incident.

• Run a short diagnostic query.

• Inspect basic schema information.

• Execute a controlled stored procedure.

• Work from a machine where installing database software is inconvenient.

It is less suitable for:

• Complex database development.

• Advanced administration.

• Large schema-management projects.

• Extensive query development.

• Long-running operational scripts.

• Workflows that require advanced debugging or database tooling.

A useful rule is:

Quick Azure investigation
        |
        v
Query Editor

Serious database development
        |
        v
Dedicated SQL tooling

Summary

Azure SQL Query Editor provides a browser-based way to run T-SQL against supported Azure SQL resources directly from the Azure portal.

It can handle common tasks such as querying tables, filtering records, joining data, running aggregations, inspecting schema information, executing stored procedures, and performing controlled data changes when the connected identity has sufficient permissions.

Its biggest advantage is speed and accessibility. Its biggest risk is making production database access feel deceptively easy.

For quick diagnostics, Query Editor can be extremely useful. For complex database development and administration, a dedicated SQL tool remains the better choice.

The best approach is to use both where they fit: Query Editor for fast, controlled investigation and full-featured database tooling for deeper engineering work.