PostgreSQL Like A Pro: Build, query, and troubleshoot without leaving VS Code

You’re building an app in VS Code. Then you need to check a table, understand how two tables connect, or figure out why a query is slow.

That often means opening another tool and finding your way back to the code.

The PostgreSQL extension for VS Code brings common database tasks into your editor. You can explore database objects, write and run SQL, and use database context with GitHub Copilot as you work.

Here are four ways to make that part of your development workflow, from finding your first table to reviewing a performance recommendation. Each section includes a video from PostgreSQL Like a Pro: VS Code Edition if you’d like to follow along.

Before writing a query, you need to know what’s in the database.

Install Microsoft’s PostgreSQL extension, then select the PostgreSQL icon in the Activity Bar to add a connection.

You can connect to on-premises or cloud databases and save connection profiles to reuse later. For a database on Azure, the Azure connection path lets you sign in with Microsoft Entra ID and select your subscription, server, and database.

Once connected, expand the server, database, and schemas to browse tables, views, functions, sequences, and extensions. Start with one table your application uses. You don’t need to understand the entire database to take the next step.

💡 Try this: Save a connection profile, then find one table your application uses and explore its structure.

PostgreSQL Like A Pro: Build, query, and troubleshoot without leaving VS CodeWatch on YouTube

You know what the application needs. Now you need a query that returns the right data.

Suppose you need to find which customers generated the most revenue in a quarter. That means joining customer and payment data, adding a date filter, and grouping and sorting the results.

The query editor’s IntelliSense helps with SQL syntax, table and column names, and join expressions. Once you have a starting query, you can ask Copilot to help refine a filter or analyze its performance using query plans and execution metrics.

For a query like this, aggregating payments before joining is one possible rewrite to investigate, not a rule to apply everywhere.

Check the results as well as the execution plan. A faster query still needs to answer the right question. Review generated SQL before running it, and compare the original and revised results.

💡 Try asking: “Analyze this query’s performance. What does the execution plan tell us, and what should I check before changing it?”

PostgreSQL Like A Pro: Build, query, and troubleshoot without leaving VS CodeWatch on YouTube

Which table contains the data you need? How does it connect to the rest of the application?

Those are often the first questions when you inherit a project.

Start broad in Object Explorer. Look for schema names, naming patterns, and tables or views that match the feature you’re working on. Then use schema visualization to trace how the relevant objects connect.

With the connected database context available in Copilot Chat, ask a focused question. For a film rental application, that might be:

Treat the answer as a starting point, not a verified map. Check the objects in the tree, review the relationships in the visualizer, and run a small read-only query to confirm that you’re following the right data path.

💡 Try this: Ask one discovery question, then verify the answer against the database before asking the next.

PostgreSQL Like A Pro: Build, query, and troubleshoot without leaving VS CodeWatch on YouTube

Connection drops and rising latency tell you something is wrong. Figuring out why usually means gathering logs, comparing metrics, and building a timeline.

Before changing anything, look for a useful chain of evidence: what changed, when it changed, which workload is involved, and why a particular action might help.

For example, repeated customer-history lookups on a large transactions table might lead to a composite-index recommendation. The next step isn’t simply to create the index. Review the supporting metrics, expected outcome, and rollback guidance first.

Database Agent brings these pieces together in the Azure PostgreSQL experience shown in VS Code. You can also ask Copilot for help understanding a recommendation before deciding what to do.

📝 Availability note: The accompanying video introduces Database Agent as an upcoming experience, with actions applied manually. Check current availability and Azure requirements; automated remediation is discussed as a future capability.

💡 Before acting: Can you explain why the change should help, how you’ll check the result, and what you’ll do if it doesn’t?

💬 Which database task takes the most detective work for you: understanding the schema, writing queries, or investigating performance? Let us know in the comments.