Running analytics and everyday business applications on one data platform sounds like a good idea. Instead of moving data between different systems, businesses could keep everything together, spend less time managing it and give their applications faster access to the information they need. And it's becoming a more realistic option.
In November 2026, Snowflake announced new real-time analytics capabilities that bring streaming data, processing and analytics closer together. But just because a platform can handle different types of work doesn't mean it's the best place to run all of them.
A system that's great at analysing huge amounts of data might not be as good at handling thousands of customer transactions at once. So while bringing everything together might make life easier, it could also create problems that businesses didn't have before.
What Does Unified Data Platform Actually Mean?
To understand what businesses are bringing together, we first need to look at the two main types of work involved. Operational and analytical workloads both use data, but they use it in very different ways. Operational workloads are the everyday tasks that keep business applications running.
Think of an online shop processing payments, updating stock levels or managing customer orders. These systems need to find, change and save individual records quickly and reliably. Analytical workloads look at data to find patterns, measure performance or help people make decisions.
For example, a retailer might analyse millions of past purchases to understand what customers are buying and predict what they'll want next. Traditionally, businesses have used separate databases for these jobs. One handles transactions, while another handles analytics. But modern unified data platforms are starting to bring them closer together.
Snowflake's Interactive Warehouses, for example, let applications and dashboards run fast analytical queries. Databricks takes a different approach with Lakebase Postgres, which provides a dedicated transactional database as part of its wider platform. There's also hybrid transactional and analytical processing (HTAP), which lets one database system handle both types of work.
TiDB does this by using different components for transactions and analytics. So when a vendor says its platform can do everything, that doesn't necessarily mean one database is doing all the work. There may still be several specialised systems working together behind the scenes.
When Does Consolidation Make Sense?
One of the biggest reasons to bring workloads together is that moving data between different systems takes time and effort. Imagine an online retailer that wants to recommend products based on what customers are buying right now.
If that information has to travel through several systems before the recommendation engine can use it, the customer might have moved on by the time the suggestion appears. Bringing data collection, processing and analytics closer together can help reduce those delays. It can also mean fewer copies of the same data, less work connecting different systems and fewer things for IT teams to keep an eye on.
Snowflake's November 2026 real-time analytics announcement is one example of how platforms are changing. Its newer capabilities bring streaming data, processing and interactive queries into the same environment, helping applications work with more up-to-date information.
This can be especially useful for things like live dashboards, customer-facing reports and applications that need to respond to recent business activity. They need fresh information, but they aren't necessarily responsible for processing the original transactions. There can be benefits for the people managing the technology, too.
Fewer separate systems to connect can mean less configuration, simpler monitoring and more consistent rules about who can access different types of data. Of course, that depends on what the business already has. If its existing systems work well together, replacing them might create more work than it saves.
Consolidation makes the most sense when different workloads need the same information and can share resources without getting in each other's way.
Where Do Unified Data Platforms Struggle?
Just because a platform supports several types of work doesn't mean it can handle them all equally well, especially when they're happening at the same time. The problems usually start when different applications need the same resources, but some can't afford to wait for others to finish.
Performance and workload isolation
Imagine an online shop processing customer orders while the analytics team runs a large report using the same data. That report might need a lot of processing power and memory. If both jobs are competing for the same resources, customers could end up waiting longer at checkout, even though nothing has technically broken. T
his is where workload isolation comes in. It simply means keeping different types of work from interfering with one another, even when they're running on the same platform. Some platforms handle this by giving different workloads their own processing resources.
Snowflake's Interactive Warehouse documentation explains that queries taking longer than five seconds are retried on a fallback warehouse, leaving the interactive warehouse available for shorter queries. It's a useful approach, but it also shows why businesses need to understand what each part of a platform is designed to handle.
A database might be fast most of the time and still struggle when thousands of people try to use it at once.
Consistency and availability
Speed isn't the only thing to think about. Businesses also need to know that the information their applications are using is correct and up to date. For example, a sales dashboard might be perfectly useful even if it's showing figures from a few seconds ago. But an application checking whether a payment has gone through needs to know what happened as soon as the transaction is complete.
HTAP systems try to handle these different needs within the same database system. According to PingCAP's TiFlash architecture documentation, TiDB copies transactional data into a separate component designed for analytics. It also checks how far that copying process has progressed so analytical queries can read consistent data.
But businesses still need to understand what happens when copying takes longer than expected, a component fails or the system needs to recover. There's also the risk of putting too many important applications in one place. If they all depend on the same platform, a problem with a shared service could affect several parts of the business at once.
Cost and vendor dependency
Having fewer systems might sound cheaper, but it doesn't always work out that way. Applications that need fast, reliable responses may require their own processing resources. Analytics might need extra capacity during busy periods, while storage, data copying and backup services can all add to the cost.
The 2026 State of Analytics Engineering Report from dbt Labs found that 57% of respondents said their warehouse and computing costs had increased, while only 36% reported larger team budgets. That doesn't mean unified platforms cost more.
But it does show why businesses need to pay attention to how much they're spending on data infrastructure, particularly when they're considering a major change. Then there's the question of what happens if they want to move to another platform later. The more applications depend on one vendor's tools, services and way of doing things, the harder it can be to move away without rebuilding parts of the system.
Sometimes keeping certain workloads separate gives a business more room to change its technology later.
When Are Separate Systems the Better Choice?
Bringing everything together isn't always the easiest or safest option. Sometimes it makes more sense to keep systems that are good at different jobs and improve how they share information. Take a payment processing application. It needs to handle transactions quickly, stay available and make sure every payment is recorded correctly.
An analytics system looking at those payments has different priorities, so there's no guarantee that running both on the same infrastructure will improve either one. Keeping them separate also means businesses can increase the capacity of one without changing the other.
If more people start using the company's reports, for example, it can give the analytics system more resources without affecting the applications customers rely on. And separate systems don't necessarily mean complicated data pipelines anymore. AWS offers Aurora zero-ETL integrations that make transactional data available in Amazon Redshift or a supported lakehouse for near-real-time analytics.
The databases still do different jobs, but AWS handles much of the work involved in moving data between them. There are limitations, of course. AWS documents restrictions around certain data types, changes to database structures and how information is copied. Some changes can even make a destination table temporarily unavailable while the system catches up.
Still, this gives businesses another way to simplify their architecture without forcing every workload onto the same system. The important thing is working out which jobs benefit from being together and which are better left to do their own thing.
What Should Enterprises Test Before Consolidating?
A platform might look impressive in a demonstration or perform well in a benchmark, but that doesn't tell a business how it'll behave with its own applications and data. Before moving workloads onto one platform, businesses need to test how everything works together under the conditions they're likely to face every day, including when things get busy or go wrong.
Test workloads together
Start by running the different workloads at the same time. That means processing transactions, running analytical queries and bringing in new data together, rather than testing each one on its own. The goal is to see whether one type of work slows down another, particularly when demand increases. Researchers from Tsinghua University and the China Software Testing Center developed HyBench, a benchmark for HTAP databases, to test exactly these kinds of situations.
It looks at transactional and analytical performance, how quickly new data becomes available and what happens when workloads compete for resources. For a business testing its own platform, the main things to check are:
- Response times: How long do applications take to respond, including when some requests are unusually slow?
- Concurrency: What happens when lots of people and applications use the system at once?
- Data freshness: How quickly does new transactional data become available for analysis?
- Resource competition: Do large analytical queries slow down everyday business applications?
What counts as acceptable will depend on the application. A few seconds might be fine for a report, but far too long for a customer waiting to complete a payment.
Test failure and recovery
It's also worth finding out what happens when something stops working.
- What if the system bringing in new data slows down?
- What if one of the processing components becomes unavailable?
- Can the business still handle customer transactions while the analytics system is recovering?
Businesses should test these situations rather than simply assuming the platform will handle them. They also need to know how long recovery takes, whether information could be delayed or lost, and which other applications might be affected.
If bringing workloads together means one failure can interrupt several important services, that risk needs to be part of the decision.
Compare the full cost and exit options
Finally, businesses need to compare what the new setup will actually cost against what they're already spending. That includes processing power, storage, moving data, monitoring, licences and the people needed to keep everything running. It's also worth looking at what happens to those costs when demand increases.
And before committing to one platform, they should consider how difficult it would be to leave.
- Could they move their data somewhere else without major changes?
- Would they need to rebuild applications or connections between systems?
- Could they still increase resources for one workload without paying to scale everything?
A platform that looks cheaper during a small trial might be much more expensive once it's running real applications at full capacity. The decision should come down to what the business actually gains in return for the money, work and risks involved.
Final Thoughts: One Platform Isn't Always the Better Architecture
Unified data platforms are making it easier for businesses to bring operational and analytical data together. But being able to run different workloads in one environment doesn't automatically mean they'll work better there. Consolidation makes sense when it removes unnecessary work without creating problems with speed, accuracy or reliability.
When applications have very different needs, keeping specialised systems can still be the better option. And as data platforms continue to take on more responsibilities, businesses will need to think more carefully about which jobs belong together and which should stay separate.
Those decisions will keep changing as technology and business needs change, too. EM360Tech's ongoing coverage of enterprise data architecture and emerging technologies can help businesses keep up with those developments and make better-informed choices.
Comments ( 0 )