Google Adds Gemini to Database Migration Service to Accelerate PostgreSQL Migrations

Google Adds Gemini to Database Migration Service to Accelerate PostgreSQL Migrations

Database modernisation projects often appear straightforward at first. Schemas can be converted, tables populated and large volumes of data transferred, but the final stage can become significantly more complicated when applications depend on years of database-specific business logic.

Google Cloud is addressing this challenge by bringing Gemini-powered code conversion into Database Migration Service (DMS). The capability is designed to help teams convert stored procedures, triggers and custom functions from commercial database platforms such as Oracle and SQL Server into PostgreSQL PL/pgSQL.

According to Google Cloud, the AI-assisted capability is intended to address what it describes as the "last mile" of database migration, where proprietary procedural logic can become a major obstacle to modernisation.

Why database migrations can become difficult

Moving database data is only one part of a migration.

Enterprise databases can contain hundreds of stored procedures, triggers, user-defined functions and other routines that encode business logic accumulated over many years.

This logic may use database-specific syntax and functions that do not have direct equivalents in PostgreSQL.

For example, an Oracle environment may contain PL/SQL routines using functions such as NVL and DECODE, along with Oracle-specific exception handling and procedural structures.

When organisations move those workloads to PostgreSQL, developers need to translate the logic while preserving its intended behaviour.

The challenge becomes particularly significant when a migration contains a large number of interconnected procedures and functions.

The traditional conversion challenge

A conventional migration process may require database specialists to:

1. Analyse legacy procedural code.

2. Identify vendor-specific syntax.

3. Map data types and built-in functions.

4. Rewrite conditional logic.

5. Adapt exception handling.

6. Check dependencies between database objects.

7. Validate the resulting PostgreSQL code.

8. Test the converted routines against application workloads.

Google Cloud says this manual conversion can require substantial engineering effort, particularly for complex enterprise schemas.

Gemini enters Database Migration Service

Google Cloud says Gemini is now integrated into Database Migration Service to assist with code conversion during the migration process.

Rather than requiring teams to move database code into a separate AI application, the conversion workflow is available within the DMS environment.

The service combines automated schema conversion with AI-generated code suggestions. Converted PostgreSQL PL/pgSQL code can be displayed alongside the original source code, allowing database teams to review the changes and make edits.

Gemini can also provide explanations for conversion decisions, helping engineers understand how specific source-database constructs were mapped to PostgreSQL equivalents.

Side-by-side migration workflow

The workflow described by Google Cloud allows teams to work through the conversion process in one environment:

Source database

Oracle / SQL Server

↓

Schema conversion

Database objects and metadata are analysed

↓

Gemini-assisted conversion

Procedures, triggers and functions are translated

↓

Review

Original and converted code are displayed side by side

↓

Validation

Converted objects are checked against PostgreSQL syntax and dependencies

↓

Staging

Converted database logic can be deployed for functional testing

↓

Production migration

Validated changes can be applied as part of the migration process

Why context matters for database code conversion

Google Cloud highlights a key distinction between AI-assisted database migration and generic code generation.

Database routines rarely exist in isolation.

A stored procedure may depend on tables, views, data types, foreign keys, functions or other procedures. Looking at one code snippet without understanding these relationships can make accurate conversion more difficult.

According to the announcement, Gemini in DMS uses broader database context during the conversion process.

This includes information such as:

• Table relationships

• Data types

• Dependent views

• Cross-procedure references

• Source database metadata

• Foreign key constraints

The goal is to give the conversion process more information about how individual database objects relate to the wider schema.

Enterprise security and project boundaries

Google Cloud also highlights security and governance as part of the integrated approach.

The company says code conversion runs within established Google Cloud project boundaries and is governed through IAM controls.

This is particularly relevant for organisations migrating databases that contain proprietary business logic.

Rather than moving database routines between multiple external tools for conversion and review, teams can work inside the Database Migration Service environment.

Google Cloud says this approach is intended to keep the conversion workflow aligned with existing project security boundaries.

Deterministic rules combined with Gemini

One of the more notable elements of the approach is the combination of deterministic conversion rules and generative AI.

Not every database transformation requires an AI model.

Some database changes can follow predictable mapping rules. Google Cloud says DMS uses compiler-based rules for well-defined transformations, while Gemini is used for more complex procedural blocks that require contextual interpretation.

The architecture therefore separates two types of conversion work:

Deterministic conversion

Used for well-defined transformations and standard syntax mappings.

AI-assisted conversion

Used for more complex procedural logic where contextual understanding is required.

This combination is intended to provide predictable handling for straightforward transformations while using Gemini for more complicated conversion scenarios.

Example: Converting Oracle PL/SQL to PostgreSQL

Google Cloud provides an example involving a procedure that calculates customer order totals and applies tier-based discounts.

The Oracle version uses NVL and DECODE. During conversion, these constructs are represented using PostgreSQL-compatible equivalents such as COALESCE and CASE.

Here is the source example provided in the announcement:

CREATE OR REPLACE PROCEDURE calculate_discount (
    p_customer_id IN NUMBER,
    p_discount OUT NUMBER
) AS
    v_total NUMBER := 0;
BEGIN
    SELECT NVL(SUM(amount), 0)
    INTO v_total
    FROM orders
    WHERE customer_id = p_customer_id;

    p_discount := DECODE(
        TRUE,
        v_total > 10000, 0.15,
        v_total > 5000, 0.10,
        0.05
    );

EXCEPTION
    WHEN NO_DATA_FOUND THEN
        p_discount := 0;
END;
/

The PostgreSQL version supplied in the announcement is:

CREATE OR REPLACE FUNCTION calculate_discount (
    p_customer_id NUMERIC,
    OUT p_discount NUMERIC
)
RETURNS NUMERIC AS $$
DECLARE
    v_total NUMERIC := 0;
BEGIN
    SELECT COALESCE(SUM(amount), 0)
    INTO v_total
    FROM orders
    WHERE customer_id = p_customer_id;

    p_discount := CASE
        WHEN v_total > 10000 THEN 0.15
        WHEN v_total > 5000 THEN 0.10
        ELSE 0.05
    END;

END;
$$ LANGUAGE plpgsql;

In this example, NVL is represented by PostgreSQL's COALESCE, while the conditional DECODE logic is represented using a CASE expression.

Google Cloud says Gemini also provides an inline explanation of these conversion decisions.

The example demonstrates why procedural migration is different from simply moving tables and records. The data may migrate successfully while application-critical logic still requires substantial conversion work.

Validation remains part of the workflow

AI-generated code does not remove the need for engineering review.

Google Cloud describes a structured validation process within DMS.

When a conversion workspace is configured, DMS can pull metadata from the source database, including schema information, data types, foreign key relationships and dependencies between database objects.

Generated code is then checked against PostgreSQL syntax rules.

The service uses validation status indicators to help teams identify objects that have been converted successfully and those requiring additional attention.

Google Cloud describes statuses such as:

• Converted

• Warning

• Action Required

This gives database teams a way to identify routines that require manual inspection instead of treating every generated conversion as automatically ready for production.

Human review remains central

The workflow also keeps engineers involved in the conversion process.

Teams can review the original and converted code side by side, examine Gemini's explanations, edit the generated PL/pgSQL and validate the changes before deployment.

This is important because database migration is not simply a syntax translation exercise.

Even when two pieces of code appear functionally similar, production workloads still need testing to confirm that the migrated application behaves as expected.

Google Cloud describes the ability to deploy validated schema and functions to a staging environment such as Cloud SQL or AlloyDB for PostgreSQL before production cutover.

What this means for database modernisation

The announcement highlights a broader industry shift toward using AI inside established enterprise workflows rather than treating AI as a separate destination.

For database teams, the important development is not simply that Gemini can generate SQL. The larger change is its integration into a migration environment that already contains database metadata, conversion tooling, validation processes and deployment workflows.

For enterprises, this could mean less manual movement between migration tools and general-purpose AI assistants.

It could also allow database administrators and application developers to spend more time reviewing migrated logic, testing applications and addressing modernisation requirements rather than manually rewriting every routine.

Google Cloud says the AI-assisted capability can help teams convert legacy database logic in days rather than months. The company did not provide specific information about this area beyond that statement.

PostgreSQL migration from Oracle and SQL Server

The capability is particularly relevant to organisations considering heterogeneous database migrations.

A typical modernisation path could involve moving:

Oracle → PostgreSQL

or

SQL Server → PostgreSQL

The target could also include managed PostgreSQL-compatible services such as AlloyDB for PostgreSQL, depending on the organisation's architecture and migration requirements.

The migration process still involves more than procedural code conversion. Teams need to consider application compatibility, database dependencies, testing, operational requirements and production cutover planning.

Gemini addresses one part of that broader process: converting database logic into PostgreSQL-compatible procedural code.

Getting started with Database Migration Service

Google Cloud directs users to Database Migration Service for migration assessments and database conversion workflows.

Teams can begin through the Database Migration Service console or review Google's heterogeneous database migration guide.

Google Cloud also references its "Gemini taught me PostgreSQL" video series, which provides examples of Oracle and SQL Server conversion scenarios.

The bigger picture

Database migration has traditionally involved a clear distinction between moving data and modernising the logic that operates on that data.

The second part can be much harder.

By integrating Gemini into Database Migration Service, Google Cloud is attempting to bring AI assistance into that final stage while keeping schema context, code review, validation and deployment within the migration workflow.

The announcement highlights a broader industry shift toward AI-assisted infrastructure modernisation, where generative AI is used alongside deterministic engineering systems rather than replacing them.

For database teams evaluating PostgreSQL migrations, the approach could reduce some of the manual effort associated with translating legacy procedural logic. However, validation, testing and engineering oversight remain important parts of the migration process.