Writing SQL with Amazon Q Developer Workspace Context
Note: This content was originally published on the AWS Blog and is reproduced here for archival purposes. Please visit the original post for the most up-to-date version.
As a developer, I love using Amazon Q Developer to accelerate development. However, when I first started using Amazon Q Developer to help with SQL queries, I quickly realized a crucial point: Q isn't connected to my database. It doesn't inherently know my tables or columns. So, how could I expect it to give me accurate suggestions? The key, I found, lies in providing the right context.
Let me walk you through a few scenarios I encountered while working with the TPC-C schema.
Scenario 1: The Importance of Open Files
Picture this: I'm staring at an empty file called
query.sql
, and I ask Q to "list the count of districts in each state". Here's what happened:
As you can see, Q took a shot in the dark. It guessed I had a "Clients" table with a "Value" column. Not even close!
What if I opened the CREATE TABLE definition for the DISTRICT table in my IDE before asking the question? Here is the definition of the district table from TPC-C data.

I asked the same question again, and voilà!

This time, Q nailed it. The open file provided the context it needed to generate an accurate query.
Scenario 2: The Power of @workspace
As my project grew, I found myself with a folder called "schema" containing definitions for all nine tables in my database. Opening individual files when needed was an option, but what about more complex queries involving multiple tables?

I decided to test Q's capabilities by asking it to "list the top carriers for each state" without any files open. The result?

Q assumed I was working with airline data. Clearly, this is wrong. My data has nothing to do with airlines.
This is where the magic of the @workspace hint comes in. By adding @workspace to my question, I instructed Q to scan my entire workspace and pick the relevant files for context. The result was impressive:

Even though I hadn't explicitly opened the CUSTOMER or ORDER table definitions, Q was able to use them to construct an accurate query. Here's a peek at the Q logs showing how it added these tables to the context:

The Game-Changer: Automatic Context Selection
What excites me most about this feature is how it eliminates the need to manually figure out which tables are relevant to my query. With @workspace, Q does the heavy lifting, sifting through my entire workspace to find the most pertinent information.
This not only saves time but also reduces the cognitive load of having to predict which table definitions I might need. It's like having a SQL-savvy assistant who's always one step ahead, anticipating my needs and gathering the right information.
Conclusion
As I continue to explore Amazon Q Developer, I'm consistently impressed by how it's evolving to meet developers' needs. The workspace context feature is a prime example of this evolution. It's not just about getting SQL suggestions; it's about getting intelligent, context-aware suggestions that truly understand your project's structure.
For anyone working with databases and SQL queries, I highly recommend giving this feature a try. It's changed the way I approach query writing, making the process smoother, faster, and dare I say, more enjoyable.
Remember, the key to unlocking Q's full potential lies in leveraging your workspace context. So next time you're stuck on a complex query, don't forget to add that @workspace hint. You might be surprised at how much easier your SQL writing becomes!