1193. Today, we talk to award-winning translator Daniel Hahn, author of "If This Be Magic," about what it really takes to translate Shakespeare, starting with the philosophical paradox at the heart of all translation: changing every single word while changing nothing at all. We look at the special challenges Shakespeare poses, including preserving rhyme and meter in languages that work completely differently.

Find Daniel's book "If This Be Magic"

🔗 Join the Grammar Girl Patreon.

🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)

🔗 Watch my LinkedIn Learning writing courses.

🔗 Subscribe to the newsletter.

🔗 Take our advertising survey.

🔗 Get the edited transcript here.

🔗 Get Grammar Girl books.

| HOST: Mignon Fogarty

| Grammar Girl is part of the Quick and Dirty Tips podcast network.

• Audio Engineer: Dan Feierabend
• Director of Podcast: Holly Hutchings
• Advertising Operations Specialist: Morgan Christianson
• Marketing and Video: Nat Hoopes, Rebekah Sebastian
• Podcast Associate: Maram Elnagheeb

| Theme music by Catherine Rannus.

| Grammar Girl Social Media: YouTube. TikTok. Facebook. Threads. Instagram. LinkedIn. Mastodon. Bluesky.

Hosted on Acast. See acast.com/privacy for more information.

Seven years after GDPR came into force, European regulators have issued over 2,245 fines totalling nearly 5.65 billion euros — and enforcement shows no sign of slowing down. Yet most compliance conversations focus on legal and governance failures, while the deeper technical root causes go unaddressed.

This article examines three recurring database-layer failures documented in the EDPB’s 2026 enforcement findings: the complexity of executing erasure across relational schemas, the backup paradox that can silently undo compliant deletions, and the audit log contradiction that traps organizations between two competing obligations.

We then look at how SQL Server, PostgreSQL, Oracle, and MySQL each handle these requirements — and where the gaps remain.

The General Data Protection Regulation (GDPR) came into force in May 2018. By March 2025 – seven years later -European regulators had issued more than 2,245 recorded fines, totaling approximately 5.65 billion euros.

That’s according to the CMS GDPR Enforcement Tracker, but it’s not the only source we have to work with. DLA Piper’s 2025 GDPR fines and data breach survey reported 1.2 billion euros in fines issued in a single twelve-month period, across financial services, healthcare, retail, energy, and the public sector.

Yes – 1.2 billion euros in fines in just one year.

Why, exactly, is this happening?

The standard explanation for persistent GDPR compliance failures is that organizations have legal and governance problems. Insufficient consent mechanisms, inadequate privacy policies, and missing data protection officers – to name a few.

None of these, however, explain where a large share of the actual failures originate. Many of the recurring compliance gaps the GDPR enforcement record documents are technical database problems that no legal team can solve, and no policy document can paper over.

On February 18, 2026, the European Data Protection Board published the findings from its 2025 Coordinated Enforcement Framework action on the right to erasure under Article 17 of the GDPR. This was the fourth CEF action in four years, and 32 Data Protection Authorities across the European Economic Area (EEA) participated.

Nine launched formal investigations and, all in all, 23 fact-finding exercises were conducted across 764 controllers – spanning SMEs, multinationals, and public sector organizations.

ReedSmith’s analysis of the report summarized its central finding plainly, identifying seven systemic weaknesses, with the two most persistent and consequential being the absence of systematic internal data classification and the lack of automated deletion mechanisms. Both of these are database engineering problems.

This article works through three specific database-layer failures that the EDPB report and enforcement record document consistently. We’ll then examine how SQL Server, PostgreSQL, Oracle, and MySQL each approach the technical requirements – and where the gaps are on each platform.

The GDPR erasure problem is a database architecture problem – here’s why

Article 17 of the GDPR grants individuals the right to have their personal data erased when it’s no longer needed for the purpose for which it was collected.

The regulation calls for erasure without undue delay. In a simple flat database, this is manageable. In any production relational database of meaningful complexity, however, it’s one of the hardest technical requirements in the regulation.

Consider a normalized e-commerce schema. A table of customers, for example, holds a ton of personal data: name, email, address, date of birth. However, deleting the customer row in the customers table does not delete the data. It breaks referential integrity on every table that references it, unless you have decided in advance what to do with each dependency.

In this instance, the options available to you are:

Cascade the deletion through all dependent tables (which may violate financial record-keeping obligations for transaction data under accounting law).

Null the foreign keys and orphan the dependent records (which corrupts data integrity).

Pseudonymize the personal identifiers – replacing them with anonymous tokens that preserve structural relationships without identifying information.

The EDPB’s February 2026 report was explicit about two recurring failures here. First, many controllers relied on anonymization techniques that were weak or amounted to mere pseudonymization, leaving re-identification risks.

Second, some controllers treated account deactivation as equivalent to erasure. A user deletes their account. The application removes the login credentials. The underlying personal data remains intact in the database. The EDPB was explicit that this does not satisfy Article 17. Deactivating an account is only a service-layer operation. Erasure means deleting or sufficiently anonymizing the personal data itself.

The backup paradox

Once the erasure is correctly executed in the live database, the compliance obligation does not end. It extends to every backup taken before the deletion occurred.

An organization taking daily database backups has a retention schedule. Backups from the last 30 days are stored online, while older backups are archived to cheaper storage. When a customer submits an erasure request, the database team correctly deletes all of that customer’s personal data from the live tables. The application then confirms the erasure.

Every backup taken before that deletion still contains the customer’s personal data in fully recoverable form. If any of those backups is restored during a disaster recovery event, a data investigation, or a development environment refresh, the deleted data reappears in the live system. The right to erasure has been satisfied in the live database, yet simultaneously undermined by the backup infrastructure.

The GDPR does not prescribe a specific technical approach to backup erasure, and supervisory authorities have taken varying positions.

The EDPB’s 2026 report found that half of the responding DPAs raised concerns that many controllers had no specific procedures for erasure in the backup context. Some controllers had no procedures at all, relying exclusively on automatic overwrite cycles. The report calls for the EDPB to issue guidance on what ‘without undue delay’ means specifically in the context of backups.

The practical compliance position, based on severalnines.com’s analysis of GDPR and database backups and enforcement practice, involves three things:

The audit log contradiction

Here’s a scenario that regularly catches well-intentioned organizations out in GDPR audits:

A data subject requests erasure. The database team executes the deletion correctly. Six months later, a supervisory authority requests evidence that the deletion was carried out.

The evidence for this should be in your audit logs. But audit logs, if they capture the content of operations, contain the personal data that was deleted. To produce the audit trail proving that you deleted the data, you must produce logs that contain the data you deleted.

This is a genuine regulatory tension between two legitimate obligations: the obligation to maintain audit trails for accountability and security, and the obligation to erase personal data on request. The resolution is to design audit logging so that it captures what happened, without capturing the content of what changed.

Building this kind of audit logging requires the following:

Data retention: why policy is not a technical control

Nearly every organization subject to the GDPR has a data retention policy. Most of them say something like: ‘personal data will be deleted after two years following the end of the customer relationship, unless legal obligations require longer retention.’

The EDPB’s 2026 report identified this explicitly: many organizations have policies but no automated deletion mechanisms to enforce them.

Data accumulates for five, seven, or ten years because the policy says two years, but nothing in the database actually enforces it.

Building automated retention enforcement in a relational database is not trivial. It requires a complete inventory of which tables contain personal data subject to retention obligations. It also requires documented mapping of legal retention periods to specific database objects, because different data categories have different requirements.

Financial transaction data, for example, may have a legal obligation to be retained for seven to ten years under accounting law – even after the customer relationship has ended. Marketing profile data, meanwhile, may need to be deleted within months.

It requires cascade logic that handles dependent tables correctly without breaking referential integrity or downstream applications. And it requires testing that the automated deletion processes run on schedule, handle edge cases, and do not produce errors that cause the deletion jobs to fail silently.

Ultimately, this is a database engineering project. It requires schema knowledge, a data inventory, and coordination between the database team and the legal team. The latter defines the retention requirements, while the former has to actually build the implementation.

In most organizations failing GDPR audits on retention, these two teams have never had that conversation in sufficient technical detail.

Platform by platform: where does each database sit when it comes to GDPR?

SQL Server and GDPR

SQL Server has mature capabilities for most of what GDPR’s technical requirements demand.

First, SQL Server Audit provides comprehensive event logging at both the server and database level. Then there’s Always Encrypted, which allows column-level encryption where even database administrators cannot read the encrypted values without the column encryption keys. And finally, Row-Level Security enables fine-grained access control, and Transparent Data Encryption protects data at rest.

The challenge is configuration, not capability. SQL Server Audit is powerful but requires deliberate policy design to capture what GDPR audits need without capturing the personal data content of every operation.

Organizations that deployed SQL Server Audit years ago for a different compliance purpose, PCI, SOX, or internal auditing, often have audit policies that do not satisfy the Article 17 accountability requirements regulators now look for. Revisiting that configuration is work that most teams defer until an audit forces the issue.

PostgreSQL and GDPR

PostgreSQL’s native audit capabilities are limited for GDPR compliance purposes.

The core postgresql.conf logging settings can capture connections, queries, and errors. However, they’re not designed for fine-grained data access auditing, and don’t produce the structured logs that GDPR audits require without significant configuration.

The standard solution for production PostgreSQL environments handling regulated data is pgaudit. This is an open-source extension that provides session-level and object-level audit logging equivalent to what enterprise database products offer natively.

pgaudit can log who accessed which tables and when (at the row level if needed), without capturing the content of the data accessed. Organizations running PostgreSQL for GDPR-regulated workloads without pgaudit (or a commercial equivalent) frequently discover that they have no adequate audit trail for the period preceding the audit. Building the trail after the fact is not an option.

Oracle and GDPR

Oracle’s Unified Auditing, introduced in Oracle 12c and the default audit architecture from Oracle 21c onward, provides the most comprehensive out-of-box audit capabilities of the four platforms covered here.

Fine-grained auditing allows audit policies to capture specific columns in specific tables under specific conditions. Oracle Label Security provides row-level classification. And, finally, Oracle Data Masking and Subsetting enables pseudonymization at the column level.

Oracle’s compliance tooling is mature enough for GDPR requirements. The challenge is that complex Oracle environments often have audit configurations that were established during initial deployment and then forgotten about as the data processing activities of the business evolved.

An audit policy that captured what was required for a 2017 PCI audit, for example, may not capture what’s needed for an Article 17 compliance review in 2026.

MySQL and GDPR

MySQL’s audit story depends on which edition you’re running. MySQL Enterprise Edition includes the MySQL Enterprise Audit plugin, which provides comprehensive session and query-level audit logging suitable for compliance use. However, MySQL Community Edition – which a substantial number of organizations run for cost reasons – does not include a native audit plugin.

Third-party and open-source audit solutions exist for MySQL Community, but many organizations running MySQL Community for GDPR-regulated workloads haven’t implemented any of them. The result is a compliance gap that is not immediately obvious from looking at the database configuration.

An organization can have MySQL running correctly, handling data reliably, with no error logs or signs of trouble – yet not have an audit trail that could satisfy a regulatory request for evidence of erasure execution.

Why a data inventory is so important in 2026

The EDPB’s report identified the absence of systematic internal data classification as one of the two most consequential weaknesses it found. This is the root problem that makes everything else harder. Every other technical control depends on knowing what data you have, where it lives, and what applies to it.

Without a data inventory, you have the following issues:

What a data inventory must include to satisfy GDPR compliance

A data inventory for GDPR purposes is a documented record of:

In summary

For legacy systems with years of accumulated schema changes and undocumented tables, building this inventory is genuinely difficult work. Starting with the tables that receive the highest volume of erasure requests, and building outward from there, produces the most compliance value for the most effort in the shortest time.

The EDPB’s 2026 coordinated enforcement action on erasure is the fourth in four years. The 2026 action will focus on transparency and information obligations. The scrutiny is not ending with erasure. Organizations that built a data inventory to address erasure compliance are positioned to respond to the next wave. Organizations that did not, are likely to be unprepared for both.

The post It’s 2026. Why are databases still failing GDPR compliance audits? appeared first on Simple Talk.

When a platform started with total developer autonomy, teams felt overwhelmed and ended up solving the same problems in completely different ways. The company shifted to enablement over support, working together with teams intensively, and helping teams feel confident and capable, turning the right way into being the easiest way.

What if filtering thousands of rows in a grid felt as simple as typing a sentence?

Traditional filtering forces users into rigid patterns: dropdowns, exact field names, and predefined conditions. Most grids still expect users to think like developers, remember column names, pick operators, and navigate layered menus just to find what they need. It’s slow, unintuitive, and often frustrating.

Now imagine your users simply typing:

• Orders above $500,
• Show high-value customers, and
• Products under $100

…and instantly seeing exactly what they asked for.

No clicks. No confusion. Just results.

That’s the power of AI‑powered natural language filtering.

In this blog, we’ll show you how to bring this smart, natural-language filtering to life using Syncfusion^® .NET MAUI DataGrid and Azure OpenAI, so your apps feel less like tools and more like intelligent assistants.

Why natural language filtering matters

Natural language filtering transforms rigid, technical filtering into a simple, conversational experience. It lets users interact with data the way they naturally think, not the way the UI demands.

Key benefits

• Faster data discovery.
  Skip menus and get instant results by simply describing what you need.
• Zero learning curve.
  No need to remember column names, operators, or filter syntax.
• Intuitive interaction.
  Users express intent in plain English, and AI handles the complexity behind the scenes.
• Greater confidence.
  Explore data freely without worrying about making mistakes.

How it works

AI-powered filtering bridges the gap between human language and structured data by:

• Understanding intent,
• Translating it into precise filter logic, and
• Delivering accurate results instantly.

The result: Faster insights, happier users, and a dramatically simpler, more engaging data experience.

Note: Before proceeding, refer to the getting started with .NET MAUI DataGrid documentation.

Prerequisites

1. Visual Studio.
2. Create a .NET MAUI application.
3. An Azure OpenAI resource and a valid API key.

How to embed AI-powered natural-language filtering in .NET MAUI DataGrid?

Adding AI-powered filtering to the .NET MAUI DataGrid isn’t just about calling an API, it requires a clean and scalable architecture. By using the MVVM pattern, you can neatly separate UI, business logic, and data handling, while dependency injection ensures your AI services are consistently available across the app.

Step 1: Create the AI filtering service

At the core of this implementation is the AIFilterService. Its role is to convert user-friendly, natural-language queries into a structured format your DataGrid can understand and apply.

For example, a query like:

“Female employees with rating ≥ 8 and salary > 5000”

is transformed into a compact JSON-based filter plan.

Here’s what happens behind the scenes:

• A schema-aware prompt is sent to Azure OpenAI to ensure responses align with your data structure.
• The AI returns a cleaned JSON filter definition (removing code fences and noise).
• The response is then validated and parsed into strongly typed models such as FilterPlan or Condition, with support for nested filter groups.

If anything goes wrong, such as a missing configuration or invalid JSON, the service safely returns null, ensuring your app remains stable.

Refer to the following code example for implementation details.

public class AIFilterService : IAIFilterService
{
    // Converts a natural language prompt into a JSON filter plan via Azure OpenAI.
    public async Task<FilterPlan?> CreateFilterPlanAsync(string naturalLanguagePrompt)
    {
        // Ensure Azure OpenAI settings are present
        if (string.IsNullOrWhiteSpace(AzureBaseService.Endpoint) ||
            string.IsNullOrWhiteSpace(AzureBaseService.DeploymentName) ||
            string.IsNullOrWhiteSpace(AzureBaseService.Key))
        {
            return null;
        }

        // Clear instructions: JSON filter plans only, aligned with your grid schema
        var system = "You convert plain English filters into strictly valid JSON filter plans for a data grid.";
        var user   = $"Grid schema:\n{SchemaText}\n\nUser query:\n{naturalLanguagePrompt}\n\nReturn JSON only.";

        try
        {
            // Call Azure OpenAI and get raw content
            var content = await CallAzureAsync(system, user);

            // Extract compact JSON (removes ```json fences, trims noise)
            var json = ExtractJsonObject(content);
            if (string.IsNullOrWhiteSpace(json))
                return null;

            // Parse JSON into a FilterPlan (parsing implemented elsewhere)
            return ParseFilterPlanFromJson(json);
        }
        catch
        {

            // Fail safe: return null on network/parse errors
            return null;
        }
    }
}

Step 2: Configuring AI services

Once your AI filtering service is ready, the next step is to make it available throughout your app. This is done during app startup by registering your services using dependency injection.

By configuring your AI service and ViewModel at this stage, you ensure they can be easily accessed wherever needed without manual instantiation or tight coupling.

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddAiServices(this IServiceCollection services)
    {
        services.AddSingleton<IAIFilterService, AIFilterService>();
        services.AddSingleton<EmployeesViewModel>();
        services.AddTransient<MainPage>();
        return services;
    }
}

Step 3: Integrating Azure OpenAI with your .NET MAUI app

To enable natural language filtering, your app needs to connect to Azure OpenAI, which powers the understanding and interpretation of user queries.

To do so:

• First, ensure you have access to Azure OpenAI and create a deployment in the Azure portal.
• If you do not have access, please refer to the create and deploy Azure OpenAI service guide to set up a new account.
• Note down the deployment name, endpoint URL, and API key.
• Make sure you’ve installed the Azure.AI.OpenAI NuGet package from the NuGet Gallery.
• In your base service class (AzureBaseService), initialize the OpenAIClient.
• Replace the Endpoint, DeploymentName, and Key with the actual values from your Azure OpenAI resource.

public abstract class AzureBaseService
{
    internal const string Endpoint = "YOUR_END_POINT";
    internal const string DeploymentName = "DEPLOYMENT_NAME";
    internal const string Key = "API_KEY";

    protected AzureBaseService() {}
}

Next, we’ll define the models that make this integration work seamlessly.

Step 4: Creating models for AI-ready filtering

Here, we’ll use a simple Employee model and a helper repository to seed data. This keeps our demo self-contained and repeatable.

The model class defines the structures for employees, filter plans, conditions, and nodes, and helps represent user queries in a structured way for dynamic data filtering.

public class Employee
{
    public int EmployeeId {get; set;}
    public string Name {get; set;} = "";
    public string Title {get; set;} = "";
    public int Rating {get; set;}
    public DateTime BirthDate {get; set;}
    public string Gender {get; set;} = "";
    public decimal Salary {get; set;}
}

Next, define a lightweight structure that represents the AI-generated filtering logic. Instead of applying filters directly, the AI returns a compact filter plan that can be evaluated against each row.

// Represents a complete filter plan generated by AI.
public class FilterPlan
{
    public string logic {get; set;} = "and";
    public List<FilterNode> conditions {get; set;} = new();
}

public class FilterNode
{
    public Condition? condition {get; set;}
    public FilterPlan? group {get; set;}
}

Step 5: Building the ViewModel for natural language filtering

The ViewModel acts as the brain of your AI-powered filtering experience, connecting user input, AI processing, and the DataGrid in a clean, responsive flow.

It is responsible for:

• Managing user input (typed prompts or suggested queries),
• Invoking the AI service to interpret natural language, and
• Updating the DataGrid dynamically based on AI-generated filters.

At its core, the ViewModel maintains the employee collection along with the user’s prompt. It also provides ready-to-use suggestions, making it easier for users to try common queries without having to type them from scratch.

When a user enters a query like:  

“rating ≥ 8 and salary > 5000”,

… the ViewModel sends it to the AIFilterService. The AI then converts this into a structured FilterPlan. Once received, the ViewModel triggers a FilterChanged event, prompting the DataGrid to refresh and display filtered results instantly.

To apply the filter, the ViewModel exposes the BuildPredicate() method. This method converts the current filter plan into a predicate function, enabling the DataGrid to efficiently evaluate each row.

public class EmployeesViewModel : BindableObject
{
    // Helpful one-click suggestions
    public ObservableCollection<string> PromptSuggestions { get; } = new()
    {
        "Employees with rating >= 8 and salary > 5000",
        "Show only Female employees born before 1990",
        "Name contains 'Tom' or Title contains 'Supervisor'",
        "BirthDate between 01/01/1980 and 12/31/1989",
        "Salary between 3000 and 4000",
        "Gender in [Male, Female] and Rating > 5",
        "EmployeeId between 1005 and 1015"
    };

    public EmployeesViewModel(IAIFilterService ai)
    {
        _ai = ai;

        ExecutePromptCommand = new Command(async () => await ExecuteAsync());

        ResetCommand = new Command(() =>
        {
            CurrentPlan = null;
            SelectedSuggestion = null;
            Prompt = string.Empty;

            FilterChanged?.Invoke (this, EventArgs.Empty);
        });
    }

    private async Task ExecuteAsync()
    {
        var toRun = !string.IsNullOrWhiteSpace(Prompt) ? Prompt : (SelectedSuggestion ?? string.Empty);

        toRun = toRun.Trim();

        if (string.IsNullOrWhiteSpace(toRun))
        {
            CurrentPlan = null;
            FilterChanged?.Invoke(this, EventArgs.Empty);
            return;
        }

        // Ask AI to create a structured plan
        CurrentPlan = await _ai.CreateFilterPlanAsync(toRun);
        FilterChanged?.Invoke(this, EventArgs.Empty);
    }

    //DataGrid typically accepts a Predicate<object>. The ViewModel builds one from the current FilterPlan.
    public Predicate<object>? BuildPredicate()
    {
        if (CurrentPlan is null)
            return null;

        return rowObj => EvalPlan(CurrentPlan, (Employee)rowObj);
    }
}

Step 6: Designing the UI for AI-powered natural language filtering

Finally, bring everything together by creating a clean, intuitive UI that lets users interact with your DataGrid using natural language.

This layout is designed to be simple and focused, so users can type what they want and instantly see results without friction.

• Smart input at the top.
  An editable Syncfusion .NET MAUI ComboBox allows users to either type a natural language query or quickly pick from suggested prompts.
• Quick action controls.
  Two buttons: Execute Prompt and Reset make it easy to apply filters or clear them with a single click.
• Dynamic DataGrid display.
  The Syncfusion .NET MAUI DataGrid displays employee data and updates instantly when a prompt is executed. ViewModel processes the query and applies a predicate, enabling real-time, intelligent filtering.

This simple yet powerful interface ensures users can ask, apply, and explore data effortlessly, turning your DataGrid into a responsive, AI-driven experience.

<Grid Grid.Row="0"
      ColumnDefinitions="*, Auto, Auto"
      ColumnSpacing="10"
      IsVisible="{OnPlatform Android=False, iOS=False, MacCatalyst=True, WinUI=True}">

    // Editable ComboBox for natural language prompts or quick suggestions
    <input:SfComboBox
        ItemsSource="{Binding PromptSuggestions}"
        SelectedItem="{Binding SelectedSuggestion}"
        Text="{Binding Prompt, Mode=TwoWay}"
        IsEditable="True"
        Placeholder="Ask AI to apply filter to DataGrid"
        HeightRequest="40" />

    // Button to run the current prompt via AI and apply the filter
    <Button Grid.Column="1"
               Text="Execute Prompt"
               Command="{Binding ExecutePromptCommand}" />

    // Button to clear the prompt, suggestion, and any active filters
    <Button Grid.Column="2"
               Text="Reset"
               Command="{Binding ResetCommand}" />

    // Binding DataGrid
    <sfgrid:SfDataGrid Grid.Row="1"
                          ItemsSource="{Binding Employees}"
                          ColumnWidthMode="Fill"
                          SortingMode="Multiple">
    </sfgrid:SfDataGrid>

</Grid>

See the final output image for better understanding.

GitHub reference

For more details, refer to the AI-powered natural language filtering in the .NET MAUI DataGrid GitHub demo.

Supercharge your cross-platform apps with Syncfusion's robust .NET MAUI controls.

Try It Free

Switch from rigid filters to conversational data filtering

You’ve seen how AI can completely transform the way users interact with data. By combining Syncfusion .NET MAUI DataGrid with Azure OpenAI, you can replace complex, manual filtering with simple, conversational inputs, making your app faster, smarter, and far more intuitive.

Instead of forcing users to learn filters, you empower them to just ask and get results, even for complex, multi-condition queries.

So, don’t settle for traditional filtering; upgrade your app experience today with AI-powered natural language filtering.

•  Already a Syncfusion user? Download the latest Essential Studio from the license and downloads page.
• New to Syncfusion? Try the free 30-day trial and explore its full potential.
•  Need help? Connect with us via the support forums, feedback portal, or support portal. We’re here to support you.

Start building smarter, more intuitive .NET MAUI apps today and give your users an experience they’ll love.

Scan it to get the demo app.

Scan it to get the demo app.

Scan it to get the demo app.