🤖 AI

Token Optimization Strategies for LLM-Based Oracle-to-PostgreSQL Migration

This paper formalizes token optimization as a multi-objective constrained transformation problem for LLM-based Oracle-to-PostgreSQL migration, evaluating twelve strategies to demonstrate that while aggressive compression drastically reduces semantic fidelity, adaptive routing and mild context pruning offer the most effective trade-offs between token efficiency and code quality.

Original authors: Oleg Grynets, Dmytro Babarytskyi, Vasyl Lyashkevych

Published 2026-05-28

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Oleg Grynets, Dmytro Babarytskyi, Vasyl Lyashkevych

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to move a massive, ancient library from one building to another. The old building (Oracle) has books written in a very specific, complex dialect, and the new building (PostgreSQL) speaks a slightly different language. You hire a brilliant translator (an AI or Large Language Model) to rewrite every book so it makes sense in the new building.

However, there's a catch: The translator gets paid by the word (or "token") they read and write. If you hand them a library with too many words, the bill becomes astronomical, and the translator might get overwhelmed, forgetting the important parts of the story in the middle of the pile.

This paper is about finding the smartest way to trim the fat from the books before handing them to the translator, without accidentally cutting out the plot.

The Problem: Too Much Noise

The authors found that when you just dump the raw Oracle code into the AI, it's like giving the translator a book filled with:

Comments: Notes the original author wrote to themselves (e.g., "Fix this later").
Physical Details: Instructions about how the book was physically stored on a shelf (e.g., "Keep in a dry room"), which don't matter in the new building.
Extra Whitespace: Huge gaps between words.

These things take up space (tokens) but don't help the translator understand the story (the business logic).

The Experiment: 12 Ways to Shrink the Books

The researchers tested 12 different strategies to shrink the input for the AI. Think of these as different ways to edit a manuscript:

The "Clean Sweep" (Context Pruning): They simply deleted the author's notes and the shelf-storage instructions.
- Result: This was the safest bet. It saved a little money and actually made the translation better because the AI wasn't distracted by junk.
The "Squeeze" (Minification): They removed all extra spaces and newlines, squishing the text together like a compressed file.
- Result: It saved some words, but didn't improve the story much.
The "Secret Code" (DSL/Identifier Masking): They replaced long, descriptive names (like CustomerOrderProcessingTable) with short codes (like X_1).
- Result: This saved a lot of words, but the translator got confused. Without the real names, the AI couldn't guess what the table was for, leading to bad translations.
The "Gist Only" (Schema Distillation): They threw away almost everything except the bare bones of the structure.
- Result: This saved a massive amount of money (tokens), but the story became unrecognizable. The AI produced valid-looking sentences that made no logical sense.
The "Smart Editor" (Adaptive Routing): This was the winner. Instead of using one rule for every book, the system looked at each book first. If the book was simple, it used a light touch. If it was complex, it used a different strategy.
- Result: It saved a good amount of money (about 8-9% fewer words) while keeping the story 99% accurate.

The Big Lessons (The "Trade-Off")

The paper teaches us a crucial lesson about AI migration: You cannot just cut words to save money.

The "Lost in the Middle" Effect: If you make the prompt too long, the AI forgets the important instructions buried in the middle.
The "False Economy" Trap: Strategies that cut the most words (like "Distillation" or "Masking") often destroy the meaning. It's like translating a novel by only keeping the first letter of every word; it's short, but it's nonsense.
Syntax vs. Meaning: Sometimes the AI can write a sentence that is grammatically perfect (Valid Syntax) but completely wrong in meaning (Semantic Drift). You have to check both.

The Solution: The "Smart Router"

The paper concludes that the best approach isn't a single "magic eraser." Instead, it's a Smart Router.

Imagine a traffic controller at an airport.

If a plane is small and simple, they send it through a quick, light security check.
If a plane is huge and complex, they send it through a more thorough, specialized lane.

In the same way, the best strategy is to analyze the code first. If it's simple, trim the fat. If it's complex, be gentle and keep the important details. This "Adaptive Routing" approach saved money without losing the meaning of the code.

Summary

Moving databases with AI is like moving a library with a paid translator.

Don't just throw everything at the translator; it's too expensive and confusing.
Don't cut out the important names and details just to save a few cents; you'll lose the story.
Do use a smart system that decides how much to trim based on how complex the specific piece of code is. This saves money while keeping the translation accurate.

Technical Summary: Token Optimization Strategies for LLM-Based Oracle-to-PostgreSQL Migration

1. Problem Statement

The migration of legacy Oracle SQL and PL/SQL artifacts to PostgreSQL is a critical component of enterprise software modernization. While Large Language Models (LLMs) offer potential for automating this transformation, the process is currently constrained by high token consumption, long-context degradation (the "lost in the middle" phenomenon), and the risk of semantic drift.

Directly feeding large Oracle schemas, procedural logic, and migration rules into LLM prompts increases API costs and often degrades generation quality. Existing approaches to prompt compression or general Text-to-SQL generation do not adequately address the specific constraints of dialect migration, where preserving procedural semantics, schema constraints, and identifier meanings is paramount. The core problem is how to reduce the context size without losing the semantic information required for a correct, syntactically valid migration.

2. Methodology

The study formalizes token optimization as a constrained transformation problem within Specification-Driven Development (SDD). The authors propose a pipeline where the migration context (source code, specifications, rules) is transformed by a strategy function $f_i$ before being passed to the LLM generation function $G$ .

A. Taxonomy of Strategies

Twelve distinct token optimization strategies were defined and evaluated:

Baseline: Unmodified raw Oracle SQL/PL/SQL.
Context Pruning: Removal of comments and Oracle-specific physical parameters (e.g., TABLESPACE, STORAGE).
Minification: Collapsing redundant whitespace and newlines.
Semantic Compression (DSL): Mapping repetitive SQL structures to compact symbolic forms.
Metadata Augmentation: Injecting schema properties and key parameters as semantic anchors.
Context Refactoring: Removing unnecessary quote characters from identifiers.
Schema Distillation: Removing secondary procedural definitions to retain only core schema logic.
Adaptive Routing: Dynamically selecting an optimization strategy based on input structural complexity (e.g., PL/SQL percentage).
AST-Based Minification: Parsing SQL into an Abstract Syntax Tree (AST) to remove redundant nodes before serialization.
Identifier Masking: Replacing verbose table/column names with short deterministic aliases.
Output Constraint Enforcement: Restricting the LLM's system prompt to prevent conversational output, markdown, or extra formatting.
Hybrid Optimization: Combining adaptive input compression with output constraints.

B. Experimental Setup

Dataset: Two subsets of Oracle SQL/PL/SQL artifacts paired with validated PostgreSQL translations: a 10-query sample for initial validation and a 100-query sample for statistical robustness.
Model: GPT-4o was used as the target LLM.
Evaluation Metrics:
- Valid Syntax Rate (VSR): Percentage of outputs parsable as valid PostgreSQL.
- Exact Match (EM): Character-identical match to reference.
- Semantic Match (SM): Functional equivalence via AST comparison or expert evaluation.
- CodeBLEU: Structural similarity metric.
- Token Efficiency (TE): Semantic return on token cost ( $SM / (T_{in} + T_{out})$ ).

3. Key Results

The evaluation on the 100-query sample revealed significant trade-offs between token reduction and migration quality:

Safe Strategies: Context Pruning was the safest optimization, reducing input tokens by 1.19% and output tokens by 1.08% while maintaining a Semantic Match of 89.75% (nearly identical to the baseline's 89.80%).
Optimal Trade-off: Adaptive Routing provided the best practical balance. It reduced input tokens by 8.72% and output tokens by 5.49%, maintaining an 88.40% Semantic Match and increasing Token Efficiency by 6.67%.
High-Risk Aggressive Strategies:
- Schema Distillation achieved massive token reductions (81.72% input, 74.64% output) and a 132.22% increase in Token Efficiency. However, this came at the cost of a 44.50 percentage-point drop in Semantic Match, rendering the output functionally incorrect for complex logic.
- Identifier Masking reduced input tokens by 33.30% but caused a 30.08 percentage-point drop in Semantic Match, confirming that domain-specific identifiers are crucial for inferring business logic.
Output Constraints: Restricting output formatting reduced output tokens by 15.05% but degraded Valid Syntax Rate by 7 percentage points and Semantic Match by 10.78 percentage points, suggesting that overly strict constraints hinder the model's ability to generate correct SQL.

4. Key Contributions

Taxonomy Proposal: The paper introduces a formal taxonomy of twelve token optimization strategies specifically tailored for Oracle-to-PostgreSQL migration.
Problem Formalization: It frames token optimization not as simple prompt shortening, but as a multi-objective constrained transformation problem balancing cost, syntactic validity, and semantic preservation.
Empirical Evidence: The study provides a rigorous empirical comparison of these strategies across varying query complexities, demonstrating that aggressive compression often leads to semantic drift.
Decision Model: A practical strategy selection model is proposed, advising the use of mild pruning for high-fidelity needs and adaptive routing for scalable, heterogeneous migrations, while warning against aggressive distillation for procedural logic.

5. Significance and Claims

The paper claims that token optimization in LLM-based database migration cannot be treated as a unidimensional cost-reduction task. The findings demonstrate that aggressive token reduction often results in semantic degradation, making the migration output functionally useless despite high token efficiency metrics.

The primary significance lies in establishing that adaptive context compression is superior to uniform compression. By dynamically routing inputs based on structural complexity (e.g., distinguishing between pure DDL and complex PL/SQL), organizations can achieve a "safe" reduction in token usage (approx. 8-9%) without compromising the semantic integrity of the migrated code. The study concludes that successful migration relies on balancing cost against structural fidelity, where mild pruning and adaptive routing represent the most viable production strategies.