The Choice Between Continuing to Pay 3 Million Yen Annually or Switching to 300,000 Yen

The annual maintenance cost for Oracle databases ranges roughly from 2 to 4 million yen, even for small and medium enterprises. This includes licensing fees, support costs, and the salaries of engineers who can handle it. Altogether, maintaining a single database can result in millions of yen disappearing each year.

If you migrate to PostgreSQL, the licensing fee drops to zero. Even including maintenance and operations, many cases can be managed for about 300,000 to 500,000 yen annually. The difference is over 2 million yen a year. In five years, that amounts to 10 million yen. For small and medium enterprises, this sum is equivalent to the cost of a new business venture.

So, why isn’t everyone migrating? The answer is simple: the migration process itself is too expensive.

Oracle’s unique SQL syntax, stored procedures written in PL/SQL, and complex interdependencies must be deciphered by hand, rewritten for PostgreSQL, and tested. If you rely on a system integrator (SIer), estimates range from 3 million to 10 million yen. The amount saved from migration is almost equal to the cost of migration. Thus, many think, “Is it really worth it to change?”

This structure is beginning to be disrupted by AI agents.

The Content of the Paper on “Automating Database Migration with AI Agents”

A recently published study titled “A Hybrid Dependency-Aware Framework for Task Decomposition and Dynamic Agent Generation in Oracle-to-PostgreSQL Migration” is intriguing. In short, it does the following:

1. Loads Oracle SQL and PL/SQL files entirely into AI.
2. Automatically analyzes dependencies (e.g., which procedures reference which tables).
3. Breaks down migration tasks into smaller parts and dynamically generates specialized AI agents for each task.
4. Each agent converts the code to PostgreSQL-compatible format and checks for consistency.

Traditional migration tools (like ora2pg) primarily focus on mechanical syntax conversion and could not adequately handle the complex business logic involved in PL/SQL. The key point of this research is that it understands dependencies before breaking down tasks. The process that veteran engineers used to follow—”first grasp the overall picture, decide the order, and tackle them one by one”—is being replicated by AI agents.

Moreover, by combining this with a method called Hierarchical Context-Aware Graph RAG, the dependencies between codes are managed in a graph structure, enhancing conversion accuracy. This could potentially reduce the hell of situations where “changing one procedure causes another batch to stop working” after migration.

How Will the Cost Structure Change? — A Concrete Estimate

Let’s consider realistic numbers.

Traditional Migration by SIers (Assuming Small to Medium Enterprises and Medium-sized Databases):

• Current system investigation and analysis: 500,000 to 1 million yen
• SQL/PL/SQL conversion work: 1 million to 3 million yen
• Testing and validation: 500,000 to 1.5 million yen
• Migration execution and switch support: 500,000 to 1 million yen
• Total: 2.5 million to 6.5 million yen
• Duration: 3 to 6 months

Migration Utilizing AI Agents (Assuming Same Conditions):

• Automatic analysis and conversion by AI agents: 50,000 to 150,000 yen (API usage fees + tool costs)
• Human review and corrections: 100,000 to 300,000 yen
• Testing and validation (with automated testing): 100,000 to 200,000 yen
• Migration execution and switch: 50,000 to 150,000 yen
• Total: 300,000 to 800,000 yen
• Duration: 2 to 4 weeks

Of course, this is an ideal case. If Oracle-specific features (like partitioning, materialized views, Oracle Forms, etc.) are deeply utilized, there will still be parts that cannot be completed by AI alone. However, even in a hybrid model where AI handles 70-80% of the migration work and humans finalize the remaining 20-30%, costs could drop to one-tenth to one-fifth of traditional methods.

This change from “3 million to 300,000 yen” is not just a discount. It changes the structure of decision-making.

A 3 million yen investment decision requires approval from the CEO in small and medium enterprises. It involves going through a deliberation process, calculating ROI, and discussing for months whether to proceed. For 300,000 yen, a department head can simply decide, “Let’s try it first.” This difference is significantly impactful.

The True Meaning for Small and Medium Enterprises — The Emergence of Options

Here, I want to take a step back and think. The essence of this discussion is not that “Oracle is bad” or “PostgreSQL is good.”

The essence is that “companies that couldn’t move due to high migration costs can now become mobile.”

Until now, IT investments in small and medium enterprises have been based on the premise that “once chosen, it cannot be changed.” They implemented Oracle a decade ago at the recommendation of an SIer. Even if they thought it was expensive, they couldn’t switch due to the migration costs. This is a classic case of vendor lock-in.

The dramatic reduction in migration costs due to AI agents will be the key to unlocking this lock-in. Not just limited to PostgreSQL, in the future, migration costs between all databases will likely decrease. What will happen then?

You will gain the freedom to “reselect the optimal tool at the optimal time.”

Large enterprises can have dedicated teams to handle migrations themselves. Small and medium enterprises do not have those resources. That is why the benefits of cost disruption from AI agents will be most significant for small and medium enterprises. This creates a structure for reversal.

The Combination of DuckDB and RAG — Changing Operations After Migration

In addition to migration, there is another technology worth noting: the integration of RAG (Retrieval-Augmented Generation) with DuckDB.

DuckDB is an embedded analytical database that operates without installation or a server. When combined with RAG, it enables “natural language queries” against the post-migration database.

For example, if you ask the data migrated to PostgreSQL, “Show me the top 10 customers from last month and their year-on-year comparison,” the AI will automatically generate SQL and return the results. Even without personnel who can write SQL, data can be utilized.

For small and medium enterprises, the lack of personnel who can write SQL is a serious issue. Even if they reduce database costs, it is meaningless if they cannot utilize it. The RAG integration significantly lowers this barrier to utilization.

So, What Should We Do?

This is not a call to abandon Oracle immediately. However, the following three steps can be taken starting today.

1. Accurately grasp your company’s Oracle-related costs.
Licensing fees, maintenance costs, operational personnel costs. How much are you paying in total annually? Many companies do not have an accurate grasp of this. Start here.

2. Inventory the technical hurdles of migrating to PostgreSQL.
How much are you using Oracle-specific features? How many PL/SQL stored procedures do you have? What are the dependencies? Organize the current situation with the assumption that AI agents will handle it.

3. Experiment on a small scale.
There is no need to migrate the production environment all at once. Test the AI agents (using conversion tools that leverage APIs like GPT-4 or Claude) in a test environment to see how much can be automatically converted. This is an experiment that can be done in 30 minutes.

In a world where migration costs drop to one-tenth, the burden of explaining “why not migrate” will shift. That day is closer than you think.