Database professionals can use AI to improve everyday work by starting with a task they already understand, giving the assistant the context it needs, building review into the workflow and limiting what an agent can reach. The AI sessions at PASS Summit West 2026 pointed to the same lesson: the value comes from the work around the assistant, not the assistant alone.

Most database professionals don’t need another demonstration that AI can write a query. We need to know whether the query is useful, what it might have missed and whether checking it will take longer than writing it ourselves. Deciding where AI belongs in your team’s work takes more thought. You might welcome help documenting an unfamiliar procedure while being much more cautious about an agent proposing changes to production. Both involve AI, but they ask different things of the people responsible for the database.

AI was the most common theme at PASS Summit West 2026, appearing in 33 sessions. Alongside coding assistants, there were sessions on semantic models, schema conversion, automated workflows and the permissions agents need. Together, they showed where database teams can find value, and where the work behind it is easy to underestimate.

Where should you start with AI in database work?

Start with a familiar problem, not a list of tools. Documentation is a good example. A colleague inherits a database, finds a complicated stored procedure and needs to understand what it does before changing anything. An assistant can help explain the code and produce an initial description. The colleague still needs to check that explanation, but they have something to work from.

The development sessions at PASS Summit West reflected that practical emphasis. Taiob Ali’s session on AI tools in the SQL world focused on bringing available capabilities into daily work, including GitHub Copilot in SSMS and AI search in your database. Anupama and Bhaskar Natarajan’s session on VS Code and Copilot covered query generation, refactoring stored procedures and running CI/CD pipelines. Deborah Melkin’s AI essentials session was built around sorting what’s useful in the hype cycle from what’s a distraction.

The range of tasks matters. Writing code is only one part of database development, and it may not be the part frustrating your team most. Understanding an inherited system or keeping documentation current can take up time that rarely shows up in a conversation about developer productivity. There’s also a difference between helping an experienced person move faster and helping someone attempt unfamiliar work. The latter can be valuable, but the review needs to reflect the person’s ability to recognize a mistake. A convincing explanation is hard to challenge when you’re still learning the subject.

For a useful experiment, choose a task you already understand. Compare the time and effort involved in completing it with and without assistance, including the corrections. Look at whether the result is easier for a colleague to understand. If the assistant saves ten minutes at the beginning and creates twenty minutes of investigation later, you’ve learned something worth knowing.

Why does context matter when AI writes or explains SQL?

A query can execute successfully and still answer the wrong question. Perhaps “active customer” has a particular definition in your organization. Perhaps a relationship between tables behaves differently from what the column names suggest. These details are familiar to the people working with the data and often invisible to an assistant, which can’t account for information it has never been given.

Sajitha Sritharan’s session on grounding agents with Fabric semantic models addressed this directly, with a focus on business definitions and context. It sat alongside sessions on using AI to build and maintain the models themselves, such as Reid Havens’s work with LLMs on semantic models, documentation and standards. That creates an interesting dependency. AI can help build the structures that explain data while relying on those same structures to interpret it correctly. The definitions, relationships and standards need owners who understand them.

Schema conversion exposes a related problem. Marcelo Fernandes’s session looked at what generative AI gets right and wrong when converting database code. When you move between database engines, familiar syntax can hide differences in behavior. A converted procedure can look convincing while handling a data type, transaction or error condition differently, so reviewing it takes knowledge of both the source and the destination.

These sessions show how much database expertise still matters. Someone needs to identify which assumptions are safe, supply missing context and recognize when an answer deserves a closer look. It also gives you a better question to ask when you evaluate a tool: what information can it use, and can you inspect the evidence behind its response? An explanation that leaves you unable to tell where the answer came from still leaves you with an investigation to do.

How do you turn one person’s experiment into a team workflow?

An experiment can work well on one person’s laptop and remain difficult for anyone else to use. The original author knows which information to provide. They recognize the mistakes because they’ve seen them before. They may also be making corrections that never get recorded. Hand the same workflow to a colleague and those invisible steps become obvious.

Ginger Grant’s pre-conference session on building an AI-enabled Fabric practice tackled the move toward repeatable working methods, with reusable patterns and automated quality checks and guardrails.That’s where teams need to look beyond the output of a single interaction. If a workflow is useful enough to share, its review process has to be shareable too. For generated SQL, returning rows is only the beginning. Record what information the workflow needs, what reviewers should look for, and which checks must pass, such as whether the query returns the intended rows, handles edge cases and performs acceptably against your workload. Colleagues should be able to understand why a result was accepted, and recognize when the same approach is unsuitable for a different task.

Keep examples of failures as well as successes. A convincing but incorrect answer can teach the next person more than a collection of successful prompts. Over time, those examples show the team where the assistance holds up and where it needs supervision.

What changes when AI agents can take action?

The agent sessions introduced a further consideration: what happens when AI can perform a task, not just leave a suggestion for someone to inspect? An agent connected to database tools operates within permissions someone has granted, so both its usefulness and its potential impact depend partly on those permissions. Tyler Garner’s session on governing AI agents looked at defining what an agent can touch and proving it afterward. Chanpreet Singh’s session covered governed, observable foundations for agents across SQL Server, PostgreSQL and cloud-native stores. A session on secure text-to-SQL chatbots with PostgreSQL showed how row-level security, schema pruning and query validation stop a chatbot leaking data it shouldn’t see.

For database professionals, this brings familiar responsibilities into the AI discussion. Identities need to be identifiable. Access needs a purpose. Actions need enough traceability for someone to investigate them afterward. Scope matters too. Give an agent a narrowly defined task first, so the team can learn how it behaves and whether the surrounding controls are adequate before its role expands.

Redgate’s own sessions came back to the same ground. Our keynote, Cleared for takeoff, asked how to embrace AI across the database lifecycle without losing visibility, governance and control. In Who’s really logged in?, John Martin and I walked through a scenario where an AI assistant’s access quietly grows beyond what anyone intended, and the practices that keep it in check. At the AI;BDR luncheon, the panel took on when it’s defensible to put AI into the data layer.

What should you take back to your team?

The program offered different starting points depending on your work. A developer might find immediate use in help with unfamiliar code. An analytics team might need to examine the definitions behind AI-generated answers. A DBA may be more concerned with finding the assistants already connecting to the estate. Those priorities can coexist, though they need a conversation between the people experimenting and the people responsible for supporting the result.

Before you choose another tool, pick a piece of work your team wants to improve. Decide what would count as an improvement, then follow the assisted task through to completion, including the checking, correction and handover. That’s how you find out whether AI is saving effort or just moving it to someone else.

Missed the keynote? The slides and video are availble. And if keeping your databases well governed and secure is also on your mind, Grant Fritchey has shared his own takeaways from PASS Summit West.