Digital sovereignty is broader than database operations. It can also include legal, regulatory, commercial and strategic considerations that go well beyond SQL Server. This article does not attempt to define all of them. The focus here is narrower: operational control. For SQL Server digital sovereignty, that means asking how much control an organization actually retains over its data. It also means asking whether the organization can operate, protect and recover the database environment when normal conditions no longer apply.

A SQL Server can run inside the company’s own data center and still depend heavily on external services. Those services may provide identity, backup, remote administration or key management. At the same time, a cloud-based SQL workload can provide clearly defined controls over administration, encryption, backup and recovery. The deployment model therefore tells us something about responsibility, but it does not answer the sovereignty question on its own.

Data location is only one layer

Data residency is an obvious place to start because databases contain information that an organization needs to protect. Teams should know where production databases, backups and replicas reside. However, location alone does not explain who controls them or what the organization can still do during an incident.

A SQL Server environment usually extends beyond its primary database files. Backups may go to another storage platform, while monitoring systems may process operational data elsewhere. Administrators or service providers may connect remotely, and encryption can depend on an external key-management system. High availability can introduce further locations and dependencies. Once those components become part of normal operations, they also become part of the question of control.

Running SQL Server on-premises gives an organization direct responsibility for many infrastructure components. Even then, not every relevant dependency sits under the same control. Remote support services, identity providers, cloud backup platforms or externally managed infrastructure may still form part of the operating model.

The reverse is also true. Moving a workload to a cloud platform does not mean that an organization automatically gives up control. What matters is which responsibilities remain internal, which the provider assumes and which technical dependencies arise from that division.

This distinction becomes especially important during incidents. Under normal conditions, most dependencies remain largely invisible because they simply work. Operational control becomes easier to judge when one of them stops working. At that point, the organization may have to continue operating or recover the service without relying on the normal path.

What SQL Server digital sovereignty looks like in practice

A useful assessment therefore starts with concrete operational questions rather than a general cloud-versus-on-premises debate. Who can access the SQL Server environment with administrative privileges? Where are the database backups, and who controls those copies? Who controls the encryption keys? Which external accounts, network paths or services does the team need to administer the environment? Most importantly, could the organization recover an important database if one of those dependencies became unavailable?

Consider a SQL Server that runs on company-owned hardware. The organization keeps the database files locally, while an external service stores the backups. Administrators authenticate through a cloud identity provider, and another external system holds important encryption keys. The production database remains on-premises, but parts of its administration and recovery path do not. That does not make the architecture wrong. It means that an assessment of operational control has to look beyond the physical location of the SQL Server.

Now consider the opposite situation. A managed database platform may provide a defined regional deployment, restricted administrative access, encryption controls and a documented recovery model. Whether that architecture meets an organization’s sovereignty requirements depends on the requirements themselves. It also depends on which dependencies the organization is willing to accept. The word cloud does not answer that question any more than the word on-premises does.

For that reason, teams should define the required level of control before they use sovereignty as an argument for or against a platform. Otherwise, the architecture decision starts with a label. Only afterwards does the organization try to determine whether the operating model actually fits.

Backups reveal recovery dependencies

Backups are particularly useful when examining operational control because they connect production, security and recovery. A backup may exist and may complete successfully every night. It can still be difficult to use when it is needed.

For example, the backup files can be available while access depends on credentials owned by another team. Encryption keys may exist, but nobody has tested their recovery procedure. The backup destination might also rely on an identity service or network path that an incident has already made unavailable. None of these conditions makes the backup itself invalid. However, they change the question from “Do we have a backup?” to “Can we actually use it under recovery conditions?”

That is also why backup ownership matters. Someone needs to know where the backups reside and how the organization protects them. The team also needs to know which credentials recovery requires and how to obtain the necessary encryption keys. This is the same reason a SQL Server backup strategy should be judged by recovery readiness rather than successful jobs alone.

Encryption keys are part of operational control

Encryption introduces a similar dependency. A statement such as “the database is encrypted” or “the backups are encrypted” says little about who controls the keys. It also does not explain how administrators gain access to them or what happens when the normal key-management path fails.

SQL Server architectures can use different encryption and key-management approaches. The implementation details belong in a security or architecture review. From an operational perspective, however, the question is more direct: can the organization identify the keys required to recover its important databases? Can the responsible team access those keys when recovery is actually necessary?

For encrypted backups, the recovery dependency is explicit. Microsoft explains in its documentation on SQL Server backup encryption that the certificate or asymmetric key used for encryption must be available on the restore instance. Without it, the backup cannot be restored. This makes key custody part of the recovery design, not only a security setting.

This dependency also matters for SQL Server digital sovereignty. A database may rely on one key-management mechanism, while the backup platform uses another identity or access path. Such an architecture can be technically sound. Yet the organization may still have an operational blind spot if nobody has mapped or tested those dependencies.

Recovery makes operational control visible

Normal operations can hide those blind spots for years. Applications connect successfully, backup jobs complete, monitoring remains green and administrators sign in through the normal authentication path. None of that necessarily tests whether the organization could still operate after losing one of those services.

An incident changes the conditions. Identity services can become unavailable, network routes can fail and credentials may no longer work as expected. Administrators can also lose access to provider accounts. In a larger outage, several services that appear independent during normal operation may fail at the same time.

This is why recovery testing provides one of the most practical ways to examine operational control. It exposes which systems the organization actually needs. At the same time, it challenges assumptions that day-to-day operation rarely tests.

For an important workload, a restore test should therefore go beyond confirming that SQL Server can execute RESTORE DATABASE. The team also needs to obtain the required credentials and keys, reconnect the application and return the service to an acceptable state. A technically successful restore is important, but it represents only one part of service recovery.

If recovery depends on external components, that does not automatically make the design unsuitable. Most modern environments contain services and platforms outside a single team’s direct control. Removing every external dependency would often add more complexity than value. What matters is whether the organization knows those dependencies, understands their effect on recovery and has consciously accepted the resulting operational risk.

Platform choice should follow the control requirements

Sovereignty discussions can easily turn into platform discussions. On-premises SQL Server, SQL Server on virtual machines, managed Azure SQL services and other hosting models distribute responsibility differently. Each model gives an organization direct control over some components while transferring responsibility for others. Starting with a preferred platform can therefore reverse the decision process.

One organization may require strict control over administrative identities while accepting managed infrastructure. Another may need independent control over backup copies because of its recovery requirements. A third may consider workload portability an important part of its broader technology strategy. These are different requirements, even though all of them can appear in a sovereignty discussion.

Once teams define those requirements clearly, architects can compare platforms against the required level of control, operational complexity, support model, cost and recovery capability. Without that step, labels such as on-premises, European cloud or sovereign cloud provide only limited information. They do not explain how the SQL Server workload will actually operate or which dependencies remain outside the organization’s direct control.

The same principle applies to existing environments. An organization does not necessarily need to redesign the architecture simply because an external dependency exists. The more useful first step is to understand what that dependency does, who owns it and what happens if it becomes unavailable.

Assessing SQL Server digital sovereignty through operational control

A SQL Server digital sovereignty assessment does not have to remain an abstract strategy exercise. For an existing environment, a useful review can map where production data and backup copies reside. It can also identify which administrative identities have access, who controls encryption keys and which external services support normal operation and recovery.

The goal is not to produce another inventory for its own sake. Instead, the organization needs to understand whether the current operating model still provides enough control for its requirements.

That analysis often exposes issues that reach beyond the sovereignty discussion itself. Teams may discover unclear backup ownership, undocumented administrative access or recovery procedures that depend on individual employees. They may also find infrastructure choices that nobody has tested under failure conditions. Some of those dependencies will be perfectly acceptable; others may deserve a technical or management decision.

The important part is that these dependencies become visible before an incident forces a decision under pressure. A focused SQL Server architecture or operations review can help separate acceptable dependencies from risks that require action. It can also show where control exists mainly on paper because nobody has tested the operating and recovery processes under changed conditions.

Operational control is therefore not a complete definition of digital sovereignty, and it should not be presented as one. It is, however, a part that organizations can examine, test and improve in practical terms. For a SQL Server environment, that eventually leads to a question that is far more useful than a platform label:

If an important dependency became unavailable tomorrow, would we still have enough control to operate and recover this SQL Server environment?

Foto von Hans Westbeek auf Unsplash

The post SQL Server Digital Sovereignty: Why Operational Control Matters appeared first on CraftedSQL.

At that point, the reason is probably known, and there may even be a ticket, a project document or someone who can explain exactly why the access is required. The problem tends to appear much later, after applications have changed, projects have ended and the people involved have moved to different roles, while the permissions created along the way have remained untouched.

The SQL Server still works, the application continues to run and nobody reports a security problem, so there is little operational pressure to revisit those decisions. Over time, however, the environment accumulates access that may still be technically valid while the context behind it slowly disappears.

That is where permission reviews become more interesting than simply finding accounts with elevated privileges.

The permission itself does not explain why it exists

The SQL Server permissions model gives us enough metadata to build a reasonably detailed picture of access across an instance. We can inspect server and database principals, role memberships, direct grants and Windows groups, then identify accounts that appear unusually powerful or whose purpose is unclear. Microsoft documents the relevant principals, roles and catalog views in its Database Engine permissions documentation.

That inventory is useful, but it is only the starting point because the technical configuration rarely tells the whole story. A login may have broad access because a current application genuinely needs it, or because somebody granted those permissions during a migration six years ago and nobody ever revisited the decision afterwards.

From the permission alone, those situations can look almost identical.

When I review an established SQL Server environment, I therefore want to understand more than which login belongs to which role. I want to know what uses the access today, who owns the corresponding application or process, and whether the current privilege level still matches the technical requirement.

In environments that have been running for many years, answering those questions can be considerably harder than producing the permission inventory itself. SQL Server permissions have a habit of surviving organizational and technical changes much longer than the documentation that once explained them.

Reviewing old SQL Server permissions needs context, not assumptions

The age of a login or permission is useful information, but it is not evidence that the access is obsolete.

An account may belong to an application that was retired years ago, in which case removing it may be straightforward once that dependency has been confirmed. Another account may appear equally old and equally unfamiliar, yet still belong to an integration that runs once a month, a maintenance process that is used only occasionally, or a component that becomes relevant during recovery.

A short observation period will not necessarily reveal those dependencies, and neither will the fact that nobody immediately recognizes the account name.

That creates an uncomfortable but important distinction. “Nobody knows what this account does” should trigger an investigation, but it should not automatically trigger a DROP LOGIN, just as uncertainty should not become a reason to preserve unexplained privileged access indefinitely.

Both approaches create risk.

Leaving unnecessary administrative access in place increases the security exposure of the environment, while removing access without understanding the dependency can turn a security cleanup into an availability incident. A useful permission review therefore has to deal with both sides of that problem rather than optimizing for the shortest possible findings list.

Reconstructing the dependency before changing access

Once an unusual permission has been identified, I would start reconstructing the context around it. Is the account associated with a person, an application, a SQL Server Agent job, a Windows service or another technical process? Is there evidence that the access is still used, and can somebody identify an owner who is able to confirm what that process actually requires?

If the original documentation is missing, the answers may have to come from several places, including job ownership, service configurations, Windows group memberships, application settings or authentication activity. The exact investigation depends on the environment, but the objective remains the same: gather enough evidence to distinguish required access from access that merely survived.

An account that cannot yet be classified should remain visible as an unresolved finding. Lack of context is itself an operational problem because it means that nobody currently has enough information to make a safe decision about that part of the system.

In practice, permissions are often only one part of a broader SQL Server security review. Service accounts and administrative access can expose the same underlying problem from another direction: access still exists, but the reason for it is no longer sufficiently understood.

Why service accounts complicate SQL Server permissions reviews

Service accounts are a good example because they can remain unchanged for much longer than the people who originally configured them.

An account may have been created during the first deployment of an application, received additional privileges during a later migration and then continued running quietly through several upgrades. Years later, the application is still business-critical, but nobody can explain whether all of the SQL Server permissions accumulated by its service account are still necessary.

Sometimes the answer is straightforward once the application owner becomes involved. In other cases, the account has become part of a chain of technical dependencies that crosses SQL Server, Windows services, scheduled tasks and application components, which makes a seemingly simple permission change much harder to evaluate safely.

This is why the privilege level alone does not tell me enough.

If a service account has broad access, I want to know what would stop working if that access were reduced and whether the answer is based on current knowledge rather than on fear of touching an old system. Microsoft also recommends running SQL Server services with the lowest possible user rights and avoiding unnecessary additional permissions for service accounts; the details depend on the service and account type, but the underlying principle is clear. See Configure Windows Service Accounts and Permissions for the current Microsoft guidance.

If nobody can explain what the service account actually requires, the permission problem is accompanied by a second problem: the organization has lost part of the operational knowledge needed to change the system safely. That does not make the current access acceptable, but it changes the next step because the dependency first has to be understood well enough that the change can be controlled.

Least privilege is also a production change

The principle of least privilege is simple enough: an account should have the permissions it requires and no more. Applying that principle to a production environment that has grown organically for ten or fifteen years is less simple because reducing permissions changes something that another component may depend on.

For significant permissions, I therefore treat remediation like any other production change. Before removing or reducing access, I want to understand the expected dependency, know how the result will be validated and have a realistic rollback path if the assumption turns out to be wrong.

The amount of effort should match the possible impact. Removing an obsolete user from an unused development database does not require the same level of preparation as changing the account behind a business-critical application, but both changes should be based on more than the appearance of a permission in a report.

This is also where some security reviews become less useful than they could be.

A large findings list creates visible activity, yet it does not necessarily tell the organization what should happen next. If twenty accounts are marked because they are old, another ten because they have direct grants and several service accounts because they appear highly privileged, the technical observations still need to be translated into priorities.

An undocumented account with server-wide administrative privileges deserves different attention from an old database user with limited access to a non-production database. Likewise, a service account supporting a critical workload may require more careful investigation than several obviously obsolete logins whose dependencies have already been ruled out.

Age matters, privilege matters and scope matters, but so do workload importance, current usage and the ability to explain why the access still exists.

A useful review should lead to decisions

At the end of a SQL Server permissions review, I do not expect every account to fall into the same category.

Some permissions will be appropriate and can remain unchanged. Others will still be required, although the current privilege level is broader than necessary and should be reduced. Some accounts will turn out to be obsolete and can be prepared for removal, while another group will require further investigation because the available evidence is not yet good enough for a safe decision.

That last group should not be hidden simply because it makes the review look unfinished. In a mature environment, identifying where operational knowledge is missing can be just as useful as identifying an excessive grant, because it tells us where future changes are likely to carry unnecessary uncertainty.

For the important accounts, the review should eventually make three things clear: why the access exists, whether the current permissions are still justified, and who is responsible for that decision.

Once those questions can be answered, changing the technical configuration is usually the easier part.

This is why historically grown permissions concern me more than many newly granted ones. A recent change normally still has context around it, whether that is a ticket, a project, a deployment or simply somebody who remembers why the decision was made.

Older permissions may have survived several generations of applications, administrators and operating procedures while continuing to work exactly as they always did.

The access did not disappear.

The knowledge around it did.

And when privileged access can no longer be explained, that is a good reason to investigate it before either blindly accepting it or blindly removing it.

Foto von Toolmash Expo auf Unsplash

The post When Permissions Outlive Their Context in SQL Server appeared first on CraftedSQL.

What made the event particularly useful was the combination of technical content and direct conversations with speakers, DBAs, consultants and other data professionals.

I had also submitted sessions for Data Saturday Rheinland myself. Although I attended as a participant this time, I was prepared to step in at short notice when one of the scheduled speakers had to cancel.

In the end, the organisers found another replacement, but being available was important to me. Community events depend on people who are willing to contribute, whether through a planned session, an informal discussion or by helping when the original agenda can no longer be maintained.

That also changed my perspective on the event. I was not only there to consume content. I had prepared topics of my own, was ready to speak and paid close attention to how other speakers structured their sessions, explained technical details and interacted with the audience.

Eight hours of PostgreSQL for SQL Server DBAs

The event started on Friday with Grant Fritchey’s full-day pre-conference session:
What a SQL Server DBA Needs to Know About PostgreSQL

For someone who has spent many years working primarily with SQL Server, PostgreSQL is an interesting subject for several reasons.

More organisations are using multiple database platforms. Applications are no longer automatically built on one preferred relational database system, and SQL Server professionals increasingly encounter PostgreSQL in migrations, cloud environments or mixed technology stacks.

That does not mean that every SQL Server DBA needs to become a PostgreSQL specialist. It does mean that we should understand the main differences.

Administration concepts, configuration, indexing, execution plans, maintenance and troubleshooting may look familiar at first, but the underlying behaviour and operational assumptions are not always the same.

An eight-hour session provided enough time to move beyond a simple feature comparison. It allowed Grant to explain where SQL Server experience transfers well, where it can create false assumptions and which PostgreSQL concepts require a different mental model.

That distinction matters. Familiar terminology can sometimes be more dangerous than completely unfamiliar technology because it encourages us to assume that two systems behave in the same way.

Saturday at Data Saturday Rheinland 2026

Saturday offered several sessions that approached data platforms from very different directions.

GenAI and data literacy

Marco Nielinger presented:

GenAI for Data & Analytics: What’s Hot and What’s Not?

Generative AI is currently included in almost every technology discussion, but the practical value varies considerably between use cases. Sessions like this help separate capabilities that can already support real work from ideas that are still mainly demonstrations, experiments or marketing.

Oliver Engels and Katharina Ricken discussed:

Building Data Literacy in the Microsoft Data Platform Era

Technical platforms alone do not solve data problems. An organisation may have modern tools, centralised data and sophisticated reporting while users still struggle to interpret information correctly or make decisions from it.

Data literacy is therefore not a side topic. It influences whether investments in analytics and data platforms produce useful results outside the technical teams that build them.

Grant Fritchey returned with:

SQL Server performance and window functions

Query Performance Enhancements in SQL Server 2025

SQL Server 2025 introduces new options and changes that can affect how we analyse and improve query performance. For DBAs and consultants, the relevant question is not merely which features are new. We also need to understand when they apply, what problems they address and how they change existing troubleshooting practices.

New performance features can support diagnosis, but they do not replace the need to connect query behaviour, waits and infrastructure signals. I discussed that distinction in more detail in SQL Server Monitoring Is Not Diagnosis.

Thomas Hütter closed my personal agenda with:

Window Functions in SQL Server: Brush Up Your Skills

Window functions have been available in SQL Server for years, but they are still frequently underused or used without a clear understanding of their behaviour. Revisiting established functionality is often just as useful as learning about a new feature.

A better understanding of existing SQL capabilities can simplify queries, reduce unnecessary processing and make code easier to maintain.

The value is not limited to the sessions

The sessions were interesting, but events like Data Saturday Rheinland offer something that online training, documentation and recordings cannot fully reproduce.

The speakers are physically present.

When a detail is unclear, you can ask immediately. When a demonstration raises another question, you can discuss it directly with the person presenting it. Speakers can explain why they recommend a certain approach, where it has failed and which constraints are often missing from a simplified technical example.

That direct access changes the quality of the conversation.

The same applies to discussions between sessions.

Talking with other DBAs, consultants, service providers and platform specialists gives me a broader view of how other organisations work:

• Which problems are they currently seeing?
• How are they operating their SQL Server environments?
• Which tools and processes have worked for them?
• Where have technically reasonable approaches failed in practice?
• Why did they choose one solution instead of another?

These conversations do not always produce an immediate technical answer. Often, their value is in questioning assumptions.

A configuration or process may appear normal because it has been used in the same organisation for years. Meeting people from other environments provides a useful comparison. They may solve the same problem differently, face constraints you have never encountered or have already tested an approach you are only beginning to consider.

Community events remain relevant

Most technical information is available online. Documentation, conference recordings, blogs and training platforms make it possible to learn almost anything without travelling to an event.

But access to information is not the same as access to experience.

An in-person community event creates room for follow-up questions, disagreement, practical examples and conversations that were not planned as part of the official agenda.

Having submitted sessions myself and being ready to step in also reminded me that these events only work because people contribute their time, experience and willingness to help.

For me, that remains one of the strongest reasons to attend.

Data Saturday Rheinland 2026 offered strong speakers, relevant topics and plenty of opportunities to exchange experiences with people working on similar problems from different perspectives.

I returned with new technical input, a better understanding of several topics and, equally important, new questions to follow up on.

That is a good result from two days at a community event.

The post What I Took Away from Data Saturday Rheinland 2026 appeared first on CraftedSQL.

This matters because AI does not run in isolation. Once AI systems move closer to real business workflows, the surrounding platform becomes decisive: the data, the permissions, the integration paths, the observability, and the operational model behind it.

Agentic AI is often discussed through demos, assistants, and automation scenarios. But the more relevant question for database and infrastructure professionals is what has to be in place before those scenarios become reliable in production.

Behind every impressive AI workflow, there is still a less visible foundation: data quality, permissions, latency, integration, cost control, observability, and operational discipline.

The interface may become more intelligent. The underlying systems still have to be trustworthy.

Agentic AI data platforms change the conversation, but not the fundamentals

The term “Agentic AI” was clearly central to the event narrative.

That is not surprising. The industry is moving from AI systems that answer questions toward systems that can plan, call tools, interact with applications, and execute tasks within defined boundaries.

From a business perspective, that sounds powerful. From an operational perspective, it immediately raises harder questions.

• What data is the agent allowed to access?
• Which systems can it interact with?
• How are decisions logged?
• Who owns the outcome if an automated action is wrong?
• How do we test the behavior before it touches production processes?

These are not new concerns. They already exist in data platforms, integration systems, database operations, and enterprise applications. Agentic AI simply makes them harder to ignore.

An agent that works with weak data will produce weak decisions faster. An agent with unclear permissions becomes a security risk. An agent connected to unreliable systems will amplify operational noise. And an agent without observability becomes another black box in an already complex environment.

The AI layer may be new. The operational discipline behind it is not.

The data layer is still where reality starts

For database professionals, one of the most relevant takeaways is that Agentic AI data platforms do not reduce the importance of structured, trustworthy data.

It increases it.

Large language models can reason over text, summarize information, and generate responses. But enterprise use cases usually depend on something more concrete: customer records, transactions, policies, logs, telemetry, inventory, financial data, operational workflows, and business rules.

That data lives somewhere.

Often it lives in relational databases. Sometimes in data lakes, warehouses, search indexes, queues, APIs, or application-specific stores. In real environments, usually in a mix of all of them.

This is where the practical work begins.

Before an AI system can support decisions, the organization needs to know which data is authoritative. Before an agent can automate a process, the boundaries of that process need to be understood. Before analytics can support strategy, the underlying data model must be stable enough to trust.

This is not only an AI problem.

In practice, it is a data platform problem. In many companies, it is still very much a database operations problem.

From dashboards to actions

One of the more interesting shifts in the AI discussion is the move from showing information to helping people act on it.

That sounds small, but it changes the responsibility of the platform.

Traditional dashboards visualize signals. Monitoring tools raise alerts. Reports show trends. Query tools expose data. But in many environments, the difficult part is not seeing that something happened. The difficult part is understanding what it means and deciding what should happen next.

This is already familiar in database operations.

A dashboard can show high CPU. That does not explain whether the cause is a missing index, parameter-sensitive execution, parallelism, memory pressure, storage latency, bad application behavior, or a reporting workload running at the wrong time.

A monitoring system can show blocking. That does not automatically explain whether the real problem is transaction design, isolation level, missing indexes, deployment behavior, or application retries.

AI can help connect signals, context, and possible next steps. But only if the platform provides enough reliable context, and only if recommendations stay within clear operational guardrails.

The value is not in replacing expertise. It is in reducing the gap between signal and diagnosis.

This is also why monitoring alone is not enough. Signals only become useful when they are connected to diagnosis, context, and operational decisions. I covered this distinction in more detail in SQL Server Monitoring Is Not Diagnosis.

Cloud platforms are becoming control planes

AWS Summit Japan also showed how cloud platforms are increasingly positioning themselves as operational control planes.

Infrastructure, application runtime, data services, AI services, security, monitoring, cost management, and automation are no longer separate conversations. They are being connected into broader platform stories.

For SQL Server and database professionals, this is worth watching closely.

Even if a system remains on-premises or runs outside AWS, the direction is clear: organizations expect more automation, more integration, more observability, and faster feedback loops. They expect platforms to reduce manual work, not only host workloads.

But there is a risk.

A more automated platform is not automatically a better-operated platform.

If the underlying architecture is fragile, automation can make failure faster. If data ownership is unclear, AI can make confusion more scalable. If monitoring is noisy, agents may simply produce more noise. If cost visibility is weak, cloud-native architectures can become expensive before anyone notices.

The operational model has to mature together with the technology.

What this means for SQL Server environments

At first glance, an AWS Summit may seem far away from day-to-day SQL Server work.

The connection is stronger than it appears.

Many SQL Server environments are still at the center of critical business processes. They hold transactional data, operational history, reporting structures, application state, and years of accumulated business logic. Even when new cloud services and AI tools enter the architecture, those systems do not simply disappear.

They become part of the data supply chain.

That means classic database topics remain highly relevant:

• Performance still matters, because AI-driven workflows often depend on timely access to data.
• Security still matters, because agents and automation increase the importance of permissions and auditability.
• High availability still matters, because intelligent workflows do not help when the authoritative data source is unavailable.
• Data modeling still matters, because poor structure creates ambiguity downstream.
• Observability still matters, because automated decisions require traceable inputs and measurable outcomes.

The future does not remove the need for database expertise. It changes where that expertise connects.

A SQL Server specialist does not need to become an AI researcher. But it becomes increasingly useful to understand how databases, APIs, analytics layers, event-driven systems, and AI services interact in real architectures.

That is where many future troubleshooting and architecture questions will appear.

The uncomfortable truth: AI depends on boring reliability

The most important takeaway is also the least fashionable one: Agentic AI depends on boring reliability.

• Stable platforms.
• Clear data ownership.
• Good logging.
• Sensible permissions.
• Known recovery paths.
• Cost awareness.
• Operational discipline.
• People who understand what happens below the interface.

This is not the language of hype, but it is the language of production.

The more AI moves into business workflows, the more important it becomes to understand the systems that provide the context, execute the actions, and store the results.

That is where databases still matter.

Not because every future system will be built around a relational database. But because every serious business system still depends on reliable state, trustworthy data, controlled change, and operational accountability.

Looking beyond the SQL Server ecosystem

For a SQL Server-focused consultancy, events like AWS Summit Japan are useful because they widen the perspective.

They show where the broader platform market is moving. They make visible how cloud providers frame AI, infrastructure, analytics, developer experience, and operations as connected topics. And they help separate short-term excitement from the structural changes that are likely to affect real environments.

The practical conclusion is simple: AI will not make database operations irrelevant. It will make weak data platforms harder to hide.

Organizations that want to use AI seriously will need more than models and demos. They will need reliable systems, understood data flows, clean operational boundaries, and people who can diagnose what is happening when the abstraction leaks.

That is not new work. But it is becoming more visible.

And for those working close to databases and production systems, that may be the most important signal behind the current wave of Agentic AI data platforms.

The post AWS Summit Japan 2026: Agentic AI, Data Platforms, and the Operational Reality Behind the Hype appeared first on CraftedSQL.

This is one of the reasons why I use AI in SQL Server consulting for many parts of my work. Not as a replacement for SQL Server knowledge, and not as an authority that decides what is true, but as a tool that helps me structure thoughts, review arguments, prepare technical communication, and challenge assumptions before a recommendation is made.

That distinction is important. Using AI intensively does not mean outsourcing judgement. It does not mean replacing operational experience with generated answers. And it certainly does not mean accepting plausible text as verified truth. In my work, AI is useful because it sits next to experience, evidence, and technical review, not instead of them.

This matters especially in areas such as SQL Server performance, security, high availability, migrations, troubleshooting, and infrastructure design. The right answer rarely comes from a generic description of the technology. It depends on workload, data volume, history, risk, operating model, team capability, maintenance windows, business constraints, and the actual state of the system. AI can help organise this complexity, but it cannot understand the environment unless someone provides the relevant context and checks the result against evidence from the actual system.

Where AI helps in SQL Server consulting work

In practice, I find AI helpful in several areas that often sit between the raw technical findings and the final recommendation. It can help structure a vague problem, turn scattered notes into a clearer line of reasoning, compare possible explanations, prepare documentation, review scripts from a readability or risk perspective, or translate technical findings into language that different audiences can understand.

That can be valuable in real troubleshooting work. Many technical problems do not fail because nobody knows the syntax of a command. They fail because the situation is framed too narrowly, the wrong question is asked, visible symptoms are mistaken for root causes, or the explanation to stakeholders is too vague to support a responsible decision. In that space, AI can act as a useful sparring partner. It can help separate observations from assumptions, structure open questions, and make it easier to see where a conclusion is not yet supported by evidence.

After a SQL Server performance analysis, for example, the technical findings may include wait patterns, execution plans, blocking chains, storage latency, workload timing, and application behaviour. AI can help turn those observations into a clearer explanation: what is known, what is still uncertain, which assumptions need validation, and which recommendation is defensible. But the judgement behind that explanation still has to come from the person who understands the environment and has verified the evidence.

Why AI does not replace technical expertise

The dangerous part of AI is not simply that it can be wrong. Experienced technical people are used to incomplete information, misleading first impressions, and assumptions that need to be corrected during analysis. The more serious risk is that AI can be wrong in a very fluent and convincing way.

In technical work, that becomes relevant quickly. A generated answer may sound reasonable while ignoring the SQL Server version, edition, patch level, workload shape, HA/DR design, backup strategy, security model, or operational limits of the team that has to maintain the system afterwards. It may suggest an option that is technically valid but still a poor operational decision. It may also simplify a trade-off that should not be simplified.

This is where technical knowledge, experience, and critical review become more important, not less. AI can propose a line of reasoning, but it cannot be allowed to become the final authority. In a production environment, recommendations need to be tested against logs, metrics, configuration, architecture, dependencies, maintenance windows, rollback options, and business risk. Without that validation, the output may be polished, but it is not reliable.

The same applies to the questions we ask. Good questions are not just a matter of prompt wording. They require an understanding of the system, the problem, the boundaries, and the risk. If the environment is misunderstood, the answer may still read well, but it will be built on the wrong foundation.

Better questions lead to more useful AI results

One practical lesson from working with AI is that useful results rarely come from short, generic requests. They come from context, constraints, and clear review criteria. There is a significant difference between asking AI to “explain a SQL Server issue” and asking it to review a specific line of reasoning with information about workload behaviour, observed symptoms, timing, uncertainty, audience, and acceptable risk.

That is not just a prompt engineering detail. It reflects the same discipline that good troubleshooting requires. Before changing a setting, rebuilding an index, increasing resources, or drawing conclusions from a single metric, the first step is to understand what changed, who is affected, when the problem appears, what the system is waiting on, and which assumptions are still unsupported. AI works better when it is guided with the same kind of clarity.

In that sense, AI rewards people who can think precisely about a problem. The stronger the technical framing, the more useful the response tends to become. The weaker the framing, the easier it is to receive an answer that sounds helpful but remains too generic for the actual environment.

Where AI becomes risky in technical decisions

AI becomes risky when it is used as a shortcut for thinking. That often happens quietly: a generated explanation reads well, the structure looks professional, and the recommendation seems reasonable. Because the output is fluent, it may receive less scrutiny than it deserves.

In technical environments, that is not good enough. A recommendation for SQL Server configuration, indexing, migration, security, monitoring, or high availability must be judged against the real system. It needs to survive questions such as: Does this fit the workload? What are the side effects? What happens during failure? Can the team operate it? How do we verify improvement? What is the rollback plan? Which assumptions are still unproven?

Another important boundary is confidentiality. AI tools can support analysis and communication, but they must be used responsibly. Customer data, internal details, credentials, proprietary information, and sensitive operational context require clear handling rules. Microsoft provides dedicated data, privacy, and security documentation for Azure AI and OpenAI-related services, but convenience is never a valid reason to weaken professional judgement around information security.

The same applies to content. AI can help draft, structure, refine, and challenge technical writing, but it should not replace the experience behind the message. If a text about SQL Server operations could have been written without any real contact with production systems, it may be readable, but it does not build much trust. Technical content needs a point of view, and that point of view has to be earned in practice.

How I use AI in SQL Server consulting without handing over responsibility

My practical rule is simple: AI may support the work, but it does not own the conclusion. I use it to prepare, structure, compare, question, and refine. I do not use it as a substitute for checking the system, reading the evidence, understanding the risk, or making the final technical judgement.

That approach is especially important in consulting. Customers do not need a generated answer that sounds confident. They need a defensible assessment based on their environment. They need someone who can distinguish between a visible symptom and a root cause, between a quick improvement and a sustainable change, between a technically possible option and an operationally responsible one.

Used carefully, AI can improve the quality of that work. It can make incident summaries clearer, customer communication more precise, documentation faster to prepare, and assumptions easier to challenge before they become recommendations. But the value does not come from treating AI as an oracle. It comes from combining the tool with experience, context, evidence, and a habit of verification.

AI in SQL Server consulting makes expertise more visible

I do not see AI as a replacement for strong technical people. In many ways, I see the opposite. The more capable these tools become, the more important it is to know what to ask, what to ignore, what to verify, and where a plausible answer is still not good enough.

In SQL Server work, this distinction is essential. A production database environment is not a theoretical exercise. It has history, dependencies, operational pressure, business impact, and technical debt. Good decisions require more than a clean explanation. They require evidence, context, and judgement.

AI in SQL Server consulting can support that judgement, but it cannot replace it. Used naively, it creates confidence without enough evidence. Used carefully, it becomes a strong tool for clearer analysis, better preparation, and more precise communication. The responsibility, however, remains with the person who understands the system, validates the facts, and has to stand behind the recommendation in a real production environment.

The post Using AI in SQL Server Work Without Handing Over Responsibility appeared first on CraftedSQL.