The Enterprise Data Platform After Cloud Migration

Why Large Enterprises May Need More of Their Traditional Data Warehouse Architecture Than They Think

Over the last decade, the enterprise data warehouse landscape has undergone one of the most significant technology changes since relational database management systems became the established approach for analytical data processing. Hardware-based, on-premises systems are increasingly complemented or replaced by cloud-based platforms. Storage and processing resources can be provisioned on demand; object storage provides practically unlimited capacity at comparatively low cost, and organizations no longer need to purchase hardware years in advance to accommodate an uncertain future workload.

The advantages are substantial. A new data warehouse environment can be created in minutes rather than waiting for hardware procurement. Processing capacity can be increased when the workload grows and reduced when it disappears. Storage and compute can be scaled independently. Specialized processing engines can be added to the architecture without rebuilding the complete data platform.

Nonetheless, changing the infrastructure does not automatically change the workload.

A bank still executes regulatory processes with fixed deadlines. Customer-facing applications still require predictable response times. Thousands of users may concurrently access the same information. Batch processes still have dependencies. Data scientists still submit unpredictable queries, and business departments still expect reports to be ready when the working day starts.

The technology used to satisfy these requirements has changed considerably. The requirements themselves have changed much less.

This distinction is important because many mechanisms of traditional enterprise data warehouses are sometimes classified as legacy characteristics simply because they were implemented in a legacy platform. However, a mechanism that has existed for twenty years is not necessarily obsolete. It may simply solve a problem that has existed for twenty years.

In this article, we explore some of these problems and how they reappear in modern cloud architectures. The aim is neither to argue against cloud platforms nor to promote a return to traditional on-premises systems. Instead, we investigate which architectural principles remain useful when the underlying technology changes and how artificial intelligence may introduce another significant change to the enterprise workload.

Key Takeaways

• Cloud migration changes the implementation of a requirement, not the requirement itself.
• Workload management did not disappear. Part of it moved from allocating capacity inside one database system toward provisioning and paying for separate compute environments.
• Elasticity and efficiency are not synonyms. A highly elastic architecture can still be inefficient if excessive resources are provisioned.
• The scarce resource shifts from processing capacity to the budget assigned to processing capacity — and both have to be governed.
• Predictability is a requirement of its own. Variance matters as much as averages, for runtimes and for invoices alike.
• AI agents have no office hours, so they fill the idle periods that consumption pricing depends on — which changes one parameter of the build-versus-buy calculation.
• In a migration, the implementation must disappear. The requirement must survive.

The Workload Survives the Migration

A data warehouse exists to serve workloads. The physical infrastructure, database technology, storage architecture, and processing engine are the means toward that goal.

Consider a simplified banking environment. Regulatory reporting processes have to finish before fixed deadlines. Interactive dashboards need sufficiently short response times to remain usable. Customer-facing applications may execute small and highly selective queries that have little resource consumption but strict response-time requirements. At the same time, analytical applications can scan billions of rows and occupy significant processing resources for several minutes or hours.

From a purely SQL point of view, all these requests are queries. From an operational point of view, they have very little in common.

The problem existed long before cloud computing.

If all requests compete for the same finite processing resources, an expensive analytical query can negatively affect a small but business-critical request. Consequently, mature database environments introduced mechanisms to identify different request classes and assign resources according to their business importance.

Teradata, for example, uses the concept of workloads. A workload groups requests with common characteristics, allowing resource consumption to be monitored and prioritized. Tactical requests, strategic analytical requests, load processes, and ad hoc queries can be treated differently because their business requirements are different.

There is nothing particularly Teradata-specific about the underlying problem.

The problem can be formulated more generally:

When multiple consumers share a limited resource, one must decide how the resource is distributed among them.

Cloud platforms do not remove this problem. They provide another possible solution.

Instead of sharing a fixed pool of compute resources, independent compute resources can be assigned to different workloads. One processing cluster can serve reporting workloads while another executes data science queries. Additional resources can be provisioned when concurrency increases.

This is a powerful capability and one of the major advantages of cloud architectures. Still, workload management has not disappeared. Part of it has moved from resource allocation within a database system toward the provisioning and management of different compute environments.

The terminology changes; the requirement remains.

From Resource Contention to Resource Consumption

The difference becomes clearer when we consider the resource being managed.

A traditional hardware-based data warehouse has a more or less fixed amount of processing power available at any given time. If one workload consumes more CPU, memory, or I/O capacity, fewer resources remain available to other workloads.

The main question is therefore:

Who gets the available capacity?

Cloud computing introduces another possibility. When additional processing capacity is required, more capacity can be provisioned. One workload does not necessarily have to take resources away from another workload.

This appears to eliminate the original resource conflict, but an additional resource enters the equation: money.

Additional compute capacity has a price. More clusters, warehouses, virtual machines, or serverless processing increase consumption and therefore cost.

The question changes from:

Who gets the available capacity?

to:

Who is allowed to consume additional capacity, and at what cost?

This is not merely a financial question. It increasingly becomes an architectural one.

Suppose a reporting workload regularly conflicts with a data science workload. In a fixed-capacity system, workload management may lower the priority of the data science queries. In a cloud environment, the organization may instead isolate both workloads on separate compute resources.

The performance problem is solved.

The economic problem has potentially increased.

Neither solution is universally better. The appropriate approach depends on workload characteristics, required service levels, utilization, and the price of the additional capacity.

This illustrates an important property of cloud computing: elasticity and efficiency are not synonyms.

Elasticity describes how easily resources can be added or removed.

Efficiency describes how economically those resources are used.

A highly elastic architecture can still be inefficient if excessive resources are provisioned. Conversely, a fixed-capacity environment can be economically efficient when its resources are continuously and productively utilized.

The Cost of Isolation

Workload isolation is attractive because it establishes clear performance boundaries.

A large analytical query executed in one compute environment does not necessarily slow down an interactive reporting workload executed in another. Different environments can also be configured according to their individual requirements.

However, every isolation boundary creates another resource pool.

Consider an enterprise where ten business departments each receive dedicated compute resources. If all departments use their resources simultaneously, the isolation works as intended. If nine departments are mostly idle while one department experiences heavy demand, the economic efficiency depends on whether unused resources can be released and how quickly they can be reassigned.

Cloud platforms are well suited for this scenario because resources can often be suspended when they are not required. This is one of their strongest economic arguments.

The benefit decreases, however, when utilization increases.

If a compute environment is used for twenty minutes every day, consumption-based pricing is extremely attractive compared to permanently maintaining the same capacity.

If it runs twenty-four hours per day, seven days per week, the situation is different.

At this point, the question is no longer whether elasticity works. It clearly does. The question becomes whether paying a granular consumption price for permanently consumed resources remains the economically preferred model.

The answer depends on the actual pricing model and should be calculated rather than assumed.

The same principle applies to workload isolation. Creating an additional compute environment can be the correct performance solution but should not be considered free merely because provisioning the environment requires only a few mouse clicks or an API call.

Physical Optimization Did Not Disappear

The abstraction offered by modern cloud data platforms has removed many low-level infrastructure decisions from database users. This is generally an advantage.

A developer should not have to understand the physical location of every data block before executing a query. Cloud platforms increasingly automate data placement, partitioning, caching, statistics collection, and other optimization tasks.

Nonetheless, abstraction should not be confused with elimination.

A query reading one terabyte of data still has to process approximately one terabyte unless some mechanism allows the database engine to identify that most of the data is irrelevant. A join between large datasets still requires processing resources. Moving information across a network still consumes bandwidth and adds latency. Frequently accessed information can still benefit from being located closer to the processor than rarely accessed information.

The implementation has changed, but the underlying computer architecture has not.

Traditional database systems exposed concepts such as partitions, indices, physical data distribution, and storage organization directly to database designers. Modern platforms may hide more of these decisions or replace them with concepts such as micro-partition pruning, clustering, data skipping, caching, materialized results, or automatic optimization.

The objective is similar: reduce the amount of work required to obtain the desired result.

This is comparable to driving a modern car. The driver no longer manually adjusts the fuel mixture, ignition timing, or other parameters that were once necessary to operate an engine efficiently. The underlying physical processes have not disappeared. They have been automated.

The same applies to database architecture.

An automated physical design mechanism can be significantly better than requiring every developer to tune the storage manually. Still, somebody designing a large-scale platform should understand the mechanism sufficiently well to recognize the conditions under which the automation works and those under which it does not.

This becomes particularly important during migration projects.

When a Teradata Primary Index disappears from the target DDL, for example, the business requirement behind the old physical design does not necessarily disappear with it. The target platform may solve the same problem using another mechanism, or the original mechanism may indeed no longer be necessary.

Both cases are possible.

A migration project must find out which one applies. Some of these mechanisms fail loudly during the move; others break quietly.

Rediscovering Old Problems Under New Names

Technology development often proceeds in cycles.

In the early 2010s, relational databases and SQL were frequently described as unable to satisfy the requirements of rapidly growing data volumes. NoSQL technologies gained considerable attention and challenged both relational data modeling and SQL.

A few years later, SQL returned to many of these environments because a standardized and expressive query language, joins, and decades of accumulated knowledge around relational processing proved difficult to replace.

Cloud-based MPP data warehouses followed a similar pattern. Many principles known from earlier shared-nothing systems appeared again in new implementations, although under different names and using different storage technologies.

This should not be interpreted as a weakness of the newer platforms.

On the contrary, it demonstrates that proven architectural concepts tend to survive when they solve real problems.

The same pattern can be observed in workload management.

Traditional systems classify workloads, control concurrency, and distribute system resources.

Modern cloud architectures use independent compute pools, autoscaling rules, resource monitors, queues, budgets, orchestration policies, and FinOps processes.

The technical implementation differs considerably, but the intention is recognizable.

Resources must be allocated according to business requirements.

A Single Platform Is Not Necessarily the Goal

Another interesting development is the growing number of specialized processing engines used in modern enterprise architectures.

Object storage provides an inexpensive and scalable location for large quantities of data. Analytical SQL engines efficiently scan and aggregate this data. Relational operational databases provide low-latency access for selective requests. Streaming platforms process continuous event flows. Search engines provide specialized access patterns. Vector databases support similarity searches required by some artificial intelligence applications.

One could view this as fragmentation.

One could equally view it as specialization.

A screwdriver is not a bad hammer because it performs another task. Problems arise only when one insists on using it as a hammer.

The same applies to data platforms.

An analytical engine optimized to scan hundreds of millions of rows does not automatically have to be the optimal platform for an application retrieving one customer row thousands of times per second. Conversely, an operational database optimized for such selective access is not necessarily the best choice for enterprise-wide analytical processing.

The increasing use of multiple engines therefore makes architectural decisions more important rather than less important. This is also why a feature-by-feature platform comparison tends to answer the wrong question.

The question changes from:

Which database should we use?

to:

Which workload should execute on which engine?

This includes further questions: Where should the authoritative copy of the data reside? When should information be replicated? How is consistency maintained? How are access rights propagated? How is lineage tracked across systems? How much network traffic does the architecture generate?

A platform comprising multiple specialized engines may provide excellent performance. It also creates additional interfaces and dependencies.

Again, there is a trade-off.

Predictability Is a Requirement of Its Own

Performance discussions often concentrate on averages or maximum throughput.

A query completes in ten seconds. A system processes one million requests per hour. A cluster scans several terabytes per minute.

These metrics are useful, but enterprise environments frequently require another property: predictability.

Consider a regulatory process that normally completes in two hours and has to finish before 06:00.

Reducing its average execution time to one hour is useful.

Reducing it to thirty minutes is even better.

But if the same process occasionally takes seven hours because of concurrent workload or resource provisioning delays, the improved average is of limited value.

The business requirement is not necessarily to achieve the lowest possible execution time. It may be to guarantee that processing finishes before 06:00.

The same applies to costs.

An architecture costing one million dollars per month on average can be easier to manage than an architecture costing eight hundred thousand dollars on average if the latter occasionally generates an invoice of three million dollars.

This does not mean that fixed pricing is generally better than consumption pricing. Predictability itself simply has economic value.

The more business-critical the workload, the more relevant this property becomes.

Therefore, the performance and economics of a cloud platform should not only be evaluated by their average values. Their variance is equally important.

The Human Workload Pattern

Cloud economics benefit strongly from idle periods.

Suppose an analytical system is heavily used during eight business hours but only lightly during the remaining sixteen hours of the day. Hardware purchased for peak demand remains largely unused outside business hours.

Consumption-based infrastructure addresses this inefficiency elegantly. Resources are provisioned when required and removed when demand disappears.

Historically, a significant share of analytical workload has followed human activity. Business users start working in the morning, execute reports and queries during the day, and stop doing so in the evening. Batch processing creates another workload period, but many environments still exhibit distinguishable peaks and valleys.

Artificial intelligence may change this pattern.

The important point is not merely that AI requires significant computing power. Computers have always consumed computing power.

The more fundamental change is that AI can become an autonomous workload generator.

AI Does Not Go Home

An AI agent does not have office hours.

It can perform useful work when no employee is interacting with the system. It can continuously verify data quality, search for anomalies, generate documentation, analyze execution plans, classify information, reconcile datasets, prepare forecasts, inspect logs, identify unusual patterns, or test software changes.

Consider a simple example.

A traditional data quality process may execute once every night. If an inconsistency is discovered, a human investigates the issue the next morning.

An AI-supported process could continuously analyze incoming information. Once an inconsistency is detected, another agent could investigate related tables, compare previous processing cycles, inspect application logs, search documentation, and prepare a likely root cause before a human becomes involved.

Each individual activity may be inexpensive.

Thousands of such continuously operating processes are not. The cost model behind this shift deserves its own examination.

This introduces an interesting economic consequence.

The cloud model is particularly attractive when resources can be released during idle periods. If artificial intelligence gradually fills these idle periods with productive work, average system utilization increases.

At sufficiently high utilization, the economic advantage of avoiding idle capacity becomes smaller because there is less idle capacity to avoid.

This does not prove that owned hardware becomes cheaper than cloud computing. There are many other cost factors involved, including operations, redundancy, software, maintenance, electricity, data centers, staff, and the flexibility to react to future changes.

However, it changes one parameter of the calculation.

This parameter deserves attention.

When Elastic Workloads Become Permanent Workloads

Assume a compute environment costs only when it is running.

At ten percent utilization, consumption-based pricing has an obvious attraction. Paying for ten percent rather than one hundred percent of the available time can generate considerable savings.

At fifty percent utilization, the difference becomes smaller.

At ninety percent utilization, the economic question changes again.

The actual break-even point depends entirely on the pricing models being compared. No universal percentage exists.

The principle, however, is straightforward:

The higher the sustained utilization, the less important the ability to avoid paying for idle time becomes.

AI agents may move some enterprise workloads in precisely this direction.

This is particularly relevant because unused computing capacity may itself become valuable. If an organization owns or reserves capacity that would otherwise remain idle during the night, AI workloads can consume it for activities that were previously economically unattractive.

One could imagine an enterprise defining different classes of AI work.

• Time-critical agents receive immediate resources.
• Less important analytical agents execute when inexpensive or unused capacity becomes available.
• Experimental agents may be suspended when system load or cost exceeds a defined threshold.

This should sound familiar to anyone who has worked with enterprise workload management.

The workloads are new.

The scheduling problem is not.

Cost Governance as Workload Management

Traditional workload management controls the consumption of finite technical resources.

One query may be prevented from occupying too many processing resources because other, more important queries require them.

Cloud systems add an economic dimension.

An additional workload can often obtain additional resources rather than competing for the existing ones. However, each additional resource creates additional cost.

Artificial intelligence extends this problem further because the decision to consume resources may itself become automated.

Consider an AI agent investigating suspicious customer behavior.

The agent executes ten queries and obtains an answer with 90% confidence.

Should it execute another ten queries to reach 92%?

What about another thousand queries to reach 93%?

From a purely technical point of view, additional processing may improve the result.

From an economic point of view, the improvement may not justify the cost.

Human users implicitly make such decisions all the time. Eventually, a person decides that an analysis is good enough and stops working.

An autonomous agent needs an equivalent boundary.

Future workload management may therefore have to include an economic service level in addition to a technical one.

An agent may receive a maximum processing budget.

Another may be allowed to exceed its normal budget when a fraud probability crosses a defined threshold.

A regulatory agent may receive practically unlimited priority because failing to complete the process could cost more than the additional compute.

At this point, traditional workload management and FinOps begin to converge.

In a hardware-based system, a workload receives a share of CPU.

In a consumption-based system, a workload may effectively receive a share of money.

The units are different, but the optimization problem is surprisingly similar.

The Cost of a Query Is Becoming a Design Parameter

This development also affects application design.

For most of the history of SQL-based applications, developers primarily considered whether a query returned the correct result and whether it completed within an acceptable time.

Resource consumption mattered because inefficient queries reduced the capacity available to other workloads.

Consumption pricing adds another visible consequence: inefficient processing can directly increase the invoice.

AI makes this even more relevant because an application may generate queries autonomously.

The cost of a query therefore becomes a functional characteristic of the application architecture.

A technically correct agent that consumes one hundred times more resources than necessary is not a successful implementation simply because it eventually returns the correct answer.

This is no different from traditional performance tuning.

A query returning the correct result in ten hours is not considered well designed when the same result can be obtained in ten seconds.

The difference is that inefficient processing can now be measured not only in CPU seconds and elapsed time but directly in currency.

Governance Follows the Workload

Artificial intelligence also changes another aspect of enterprise data architecture: access governance.

Traditional applications usually have reasonably predictable data access paths. A reporting application accesses a known set of tables. An ETL process reads from one area and writes into another. Database permissions can be designed accordingly.

An autonomous agent is potentially more exploratory.

To investigate a problem, it may search across multiple datasets, metadata repositories, documents, logs, and other systems. This flexibility is precisely what makes AI useful, but it also makes access control more important.

An AI agent operating in a regulated environment needs boundaries.

• Which customer information can it access?
• For which purpose?
• May the information leave the enterprise infrastructure?
• Which model is allowed to process it?
• How is the generated result stored?
• Can another agent use this result?
• How is the processing reconstructed during an audit?

These are not questions that can be solved by the AI model alone.

They are data architecture questions.

As artificial intelligence becomes more deeply integrated into enterprise processing, data governance, identity management, metadata, lineage, and workload management will increasingly become parts of the same architecture.

Migration Should Preserve Requirements, Not Implementations

This leads us back to migration projects.

A mature data warehouse contains many technical mechanisms that accumulated over years of operation. Some are obsolete. Some are workarounds. Some exist because an old technology had a limitation that no longer exists in the target platform.

Removing these mechanisms is one of the benefits of migration.

Others, however, encode real business requirements.

Suppose a Teradata workload is assigned a high priority.

The migration team can remove the Teradata workload definition because the target platform does not use TASM.

This is technically correct.

But why was the workload prioritized in the first place?

Perhaps it supports an application requiring a two-second response time.

That requirement did not disappear.

The implementation must disappear. The requirement must survive.

The same applies to concurrency throttles, physical design decisions, processing windows, workload classifications, and resource reservations.

When migrating a mature system, one should therefore not ask only:

What does this Teradata feature do?

The more important question is:

Why was it introduced?

If the answer is an obsolete technical restriction, it can be removed.

If the answer is a business requirement, an equivalent solution must exist in the target architecture.

Confusing these two cases is one of the easiest ways to create a technically successful migration followed by operational problems.

Technical Debt Can Also Be Created by Simplification

Migration projects frequently have strong incentives to simplify.

Simplification is generally positive. Fewer components, fewer dependencies, and less custom code make an environment easier to operate.

But there is a difference between removing unnecessary complexity and ignoring necessary complexity.

Consider a traffic light at a busy intersection.

Removing it certainly simplifies the infrastructure. There is one less system to maintain, no electricity consumption, no control logic, and no possibility of a broken traffic light.

Traffic has not become simpler.

The complexity was there because competing traffic flows had to be coordinated.

The same can happen in a data warehouse migration.

Removing workload management, governance rules, data-model constraints, or operational controls may make the architecture diagram cleaner. If the underlying problem still exists, complexity will return somewhere else.

Often it returns as an operational procedure, a manual workaround, additional compute capacity, or an emergency fix.

These solutions can be considerably more expensive than the mechanism that was originally removed.

The Enterprise Data Platform Is Becoming a System of Systems

The likely future is therefore neither a return to the traditional enterprise data warehouse nor the replacement of every data service by one cloud platform.

Enterprise data environments are becoming systems of systems.

• Object storage may provide the persistent data foundation.
• Analytical engines process large datasets.
• Operational databases provide low-latency services.
• Streaming platforms process events.
• AI platforms consume information and create new workloads.
• Metadata platforms describe the environment.
• Governance systems control access.
• Orchestration connects the individual pieces.

The challenge increasingly lies in managing their interaction.

This is a familiar development in information technology. As individual components become easier to operate, more components are combined to build increasingly sophisticated systems.

Local complexity decreases while system-level complexity can increase.

The role of enterprise architecture is to manage this trade-off.

Old Knowledge Does Not Become Legacy Knowledge

The history of database technology contains many examples of ideas disappearing from attention and later returning under another name.

This should make us careful when classifying knowledge as obsolete merely because the technology in which it was acquired is no longer fashionable.

A Teradata performance tuner experienced in workload classification may not configure a cloud platform using the same commands. Still, the understanding of why workloads need different service levels remains useful.

A data modeler experienced in enterprise integration may use different storage technologies. The problems created by inconsistent customer identifiers across source systems remain the same.

A database administrator familiar with concurrency control may work with different mechanisms. The consequences of unlimited concurrent resource consumption remain recognizable.

The valuable part of experience is not memorizing the implementation.

It is understanding the problem the implementation was designed to solve.

This is why experienced people can move between technologies even when the products are fundamentally different.

The syntax can be learned. Twenty years of production problems cannot.

Architecture Has a Longer Lifecycle Than Technology

Enterprise technology has always evolved in waves.

Mainframes were followed by client-server architectures. Specialized database appliances became important for large-scale analytical processing. Virtualization abstracted hardware. Cloud computing abstracted infrastructure provisioning. Object storage separated persistent data from compute resources. Artificial intelligence is now starting to abstract parts of human analytical work.

Each wave solves problems created or left unresolved by the previous one.

At the same time, each creates new problems.

Cloud computing solved hardware provisioning constraints but introduced new questions around consumption management.

Object storage reduced storage costs but increased the importance of mechanisms that avoid reading unnecessary data.

Workload isolation increased performance independence but can create additional cost.

Artificial intelligence increases productivity but may become an autonomous consumer of computing resources.

There is no contradiction in this.

Engineering has always been about trade-offs.

The Question After the Migration

The interesting question for enterprises is therefore not whether Teradata, Snowflake, Databricks, PostgreSQL, or any other technology represents the future.

Technology selections are made for specific requirements at a specific point in time.

The more important question is which architectural principles remain valid independently of the selected technology.

A workload still consumes resources.

Different workloads still have different business priorities.

More concurrency still increases resource contention or cost.

Data still has to move between storage and processing resources.

Physical data access still affects performance.

Critical processes still require predictable completion.

Data still needs governance.

And somebody still has to decide how much infrastructure an application is allowed to consume.

Artificial intelligence adds another dimension because the consumer of the data platform is increasingly no longer only a human being.

An AI agent can generate workloads continuously, make autonomous decisions about which information to retrieve, and consume additional resources in pursuit of a better answer.

This may gradually turn cost management into another form of workload management.

In traditional data warehouses, the scarce resource was processing capacity.

In cloud architectures, the scarce resource can become the budget assigned to processing capacity.

The distinction matters technically, but from an architectural point of view both have to be governed.

Cloud migration therefore does not mark the end of enterprise data warehouse architecture.

It changes its implementation.

Many concepts developed in mature enterprise data warehouses will disappear because the limitations that required them have disappeared. Others will survive under different names because the underlying problems remain.

The difficult part is distinguishing between the two.

This is where experience matters most.

A successful migration does not reproduce the old system feature by feature. Neither does it discard decades of operational knowledge simply because the target platform provides a new architecture.

It understands why the old system evolved the way it did, keeps the requirements that still matter, and uses the capabilities of the new platform to satisfy them in a better way.

The infrastructure changes.

The architecture evolves.

The enterprise problems remain surprisingly persistent.

Frequently Asked Questions

Does cloud migration remove the need for workload management?

No. It offers another way of solving the same problem. Instead of dividing one fixed pool of capacity between competing requests, independent compute resources can be assigned to different workloads. The terminology changes; the requirement remains, and part of it moves toward provisioning, budgets and cost governance.

Are elasticity and efficiency the same thing?

No. Elasticity describes how easily resources can be added or removed. Efficiency describes how economically those resources are used. A highly elastic architecture can still be inefficient if excessive resources are provisioned, and a fixed-capacity environment can be efficient when its resources are continuously and productively utilized.

Why does predictability matter more than average performance?

Because enterprise processes are measured against deadlines, not averages. A regulatory process that must finish before 06:00 gains little from a lower average runtime if it occasionally takes seven hours. The same applies to cost: an architecture with a stable monthly invoice can be easier to manage than a cheaper one that occasionally produces an extreme bill.

How do AI agents change cloud data warehouse economics?

An AI agent does not have office hours. It can verify data quality, investigate anomalies or inspect logs continuously, which fills the idle periods that consumption-based pricing depends on. As sustained utilization rises, the economic advantage of avoiding idle capacity becomes smaller — one parameter of the calculation, not a verdict on it.

What should a migration project keep from the old data warehouse?

The requirements, not the implementations. When a workload definition, a throttle or a physical design decision disappears from the target platform, the question is why it was introduced. If the answer is an obsolete technical restriction, it can be removed. If the answer is a business requirement, an equivalent solution must exist in the target architecture.

A related argument about where the work goes: what actually threatens data engineering as a discipline.