Confluent supported the infrastructure of the company that showcased the Cricket T20 World Cup and the IPL, with 70 mn + concurrent users. In a candid chat Greg Taylor, SVP, APAC Sales, Confluent discusses with Rajneesh De, Group Editor, CXO Media & APAC Media how Confluent is leveraging the strong distribution network and the existing customer relationships since becoming an IBM company following the recent acquisition.
How does Confluent solution address the challenge of data fragmentation and data homogeneity in enterprises so that AI can be leveraged more effectively for more accurate insights?
At Confluent, we approach this through our data streaming platform, which is underpinned by technologies like Kafka and Flink, along with higher-level capabilities such as Confluent Intelligence.
Data fragmentation exists because data is sitting in silos across many different systems, formats (structured, semi-structured, unstructured), and environments. Traditionally, organizations tried to solve this using data warehouses or data lakes, and more recently, lakehouses. However, these approaches struggle with data in motion, i.e., real-time data does not get captured by those two capabilities efficiently.
Kafka addresses this by enabling the creation of topics, where multiple data sources can contribute data with shared context. Different consumers can then access only the data they need from these streams.
Rather than centralizing everything first, Confluent focuses on data in motion, allowing enterprises to act on data as it is generated. This improves both efficiency and timeliness of insights, which is critical for AI use cases.
When we talk about data coming from multiple sources, especially in large enterprises, some of these sources are structured while others are unstructured. Does your approach account for this complexity?
The beauty of our approach is that we fundamentally focus on data in motion.
If you’re dealing with batch data, that’s not where you would typically use Confluent. In such cases, you would rely on adjacent partners like Snowflake, Databricks, Redshift, or others. The constraining factor with a batch set of data processes is that time and speed is limited.
Additionally, it can be quite expensive to store and process massive volumes of unstructured data in batch systems. Our point of view is that in a fragmented data environment, the approach depends on the type of application. For analytics applications, for instance, you would typically leverage both a data streaming platform and a modern data platform, since most traditional platforms lack real-time capabilities.
What we’re increasingly seeing, however, is a shift toward a pattern we call shift-left. This means that the closer you get to where the data is produced, the data in motion, the faster you can make decisions.
It also enables you to decide, in real time, what data actually needs to be sent to the analytics engine. Traditionally, the prevailing approach has been to collect all data, store it in a data lake or lakehouse, run analytics, and then make decisions. This approach has two key drawbacks:
- First, it is expensive. Usually 60% of the data doesn’t need to go into the data lake for decision-making.
- Second, it is slower. Usually about 40% less efficient time-wise, because you’re using batch data.
Confluent’s data streaming platform addresses both of these challenges. It allows you to be more efficient with the data you choose to store and analyze, and it enables real-time decision-making for use cases such as fraud detection, quick commerce offers, or any scenario where immediate action is critical.
All of this can happen at the exact moment a user or even an agent is interacting with your dataset, which is incredibly powerful.
So, when we talk about data fragmentation, the goal isn’t to eliminate it entirely. You still want to ensure that all critical data resides within your data platform. The real question is: as data continues to proliferate so quickly, how can you manage it in a way that is both effective and efficient?
One of the persistent challenges most enterprises face is managing multiple vendors across platforms and applications. So, in terms of integration with all the multiple vendor platforms, how do you perform?
That is one of the powerful things of Confluent, because most when organizations build data pipelines, they typically involve numerous touchpoints across systems. Historically, moving data, for example, from Oracle into a pipeline required building custom integrations. These were often brittle, difficult to maintain, and heavily dependent on the individual who originally wrote the code.
Confluent simplifies this significantly. We offer over 200 pre-built connectors that integrate seamlessly across a wide range of systems—including MQ, Z Series mainframes, and Oracle. One of the most widely adopted in our portfolio is the Oracle Extreme Connector. It enables organizations to extract and expose only the data they need, without having to write or maintain custom code within the Oracle database.
The same applies with AWS, like across the broader ecosystem. Our managed connectors are continuously updated, ensuring compatibility with the latest features and releases. While customers do have the option to build their own connectors, doing so often defeats the purpose—since with Confluent, we handle maintenance, updates, and reliability at scale.
Are these connectors templatized based on the sector or specific applications where they are used?
It’s fundamentally about how endpoints are defined and connected, and those endpoints can be virtually anything. We see this as a critical part of the strategy. When working with Confluent, the focus is typically on solving specific business use cases. At its core, the problem is about enabling data to move seamlessly from one point to another, while maintaining integrity across the stream.
With Kafka, this is enabled through the concept of topics. These topics can be structured around specific data elements, for example, name and address. Even if a source system contains 25 different data fields, a given topic may only extract two of those, while another may carry a broader set of attributes. Essentially, it depends on what the data pipeline is designed to capture and process.
This approach makes the system significantly more efficient and scalable, as it allows for precise, need-based data movement without unnecessary overhead.
Beyond this efficiency of scale through the connectors, what would be Kafka’s unique differentiators against other competitors?
These systems are inherently complementary. We have developed a product called Tableflow in collaboration with Databricks and Snowflake.
One of the biggest challenges in data pipelines is what happens after data is pulled from the source. It needs to be transformed, enriched with context, and then loaded into a data lake or lakehouse. Typically, this involves standard formats such as Iceberg or Delta, which are the most widely used today. Tableflow addresses this challenge by supporting both formats. It enables real-time data with context already intact to be directly written into the appropriate lakehouse format: Snowflake for Iceberg and Databricks for Delta.
This allows organizations to populate their data warehouses more efficiently, while also enabling seamless movement of data in and out of these systems.
When viewed from a business perspective, especially in a scenario where multiple vendors are pitching to the same customer, does it truly make business sense?
The primary reason to work with Confluent and Tableflow is the need to have systems backed by Kafka. It is well established that Kafka offers some of the fastest capabilities for processing and transmitting data, particularly when combined with Flink.
While similar outcomes can be achieved with the other vendors we discussed, it typically requires additional layers of effort. Someone has to take on the processing work, and there is also the added responsibility of managing how the data is stored, categorized, and organized once it resides in the database.
In a traditional lakehouse architecture, data is often structured across bronze, silver, and gold tables. But what if you could directly ingest only the data that is ready for the gold layer? This would significantly reduce processing requirements, minimize human or manual intervention, and make the entire system more manageable.
With Tableflow, this becomes possible. Data can be ingested, enriched with the necessary attributes, and written directly into formats such as Iceberg or Delta. The result is a substantial saving in time which directly translates to reduced people costs as well as a significant reduction in downstream processing overhead.
How has the response been among enterprise customers for Confluent Intelligence?
We are beginning to see early signs of uptake, although adoption in India has been slightly slower so far.
At this stage, the uptake has been gradual. We have announced the core capability and are now progressively rolling out additional features. A key aspect of this evolution is the integration of AI agents, which require a fundamentally different kind of context and architectural approach.
From an enterprise standpoint, adoption is also influenced by deployment models. Organizations are evaluating multiple models, including cloud, on-prem or hybrid. This flexibility is critical, especially when compared to other vendors that primarily offer cloud-only solutions.
What is the proportion of on-prem vs cloud today?
It depends on the customer and the market. This particular market is slightly more cloud-leaning, primarily due to a higher penetration of digital-native companies.
However, the BFSI sector remains largely on-prem. This is driven by the sensitivity of data, along with stringent security requirements and regulatory frameworks that banks must adhere to.
Most banks and commodities exchanges operate under deep regulatory constraints. While they are technically capable of moving to the cloud, government regulations often restrict such transitions. However, what’s increasingly compelling is the ability to operate across all three models: on-prem, cloud, and hybrid, depending on the specific workload.
Not all workloads require the same level of regulation. For those that don’t, cloud offers clear advantages in terms of efficiency, continuous updates, and ease of management. We handle the upkeep, ensure systems remain current, and provide strong operational visibility.
Organizations must manage updates themselves on-prem, and there is typically less instrumentation available for us to assess whether the architecture is optimally set up.
To address this, we are currently working on the initial components of Confluent Private Cloud. This includes a gateway that bridges on-prem and cloud environments, enabling organizations to seamlessly connect the two. The goal is to enhance visibility and interoperability without requiring any disruption to existing systems.
Overall, if we look at the balance, it is slightly skewed towards the cloud with more than 50% on cloud and less than 50% on-prem.
Digital-native companies are inherently more tech-savvy, whereas banks, BFSI organizations, and manufacturing enterprises tend to be more legacy-oriented. In many such organizations, data and analytics teams may not always have the relevant skill sets, and manageability can become a challenge. This raises an important question: how much hand-holding is required from your side to support enterprise data teams?
Typically, the customer lifecycle begins with the adoption of open-source Kafka (OSK). Organizations quickly realize that it is a highly capable system—enabling efficient, fast, and cost-effective data movement from point A to point B through robust pipeline mechanisms. However, the challenge lies in manageability. With open-source Kafka, the responsibility for managing and maintaining the system rests entirely with the customer. As a result, we often see a pattern: when something fails or falters, enterprises turn to Confluent and seek a managed solution.
At that stage, we provide deep management capabilities, including support and hands-on assistance with implementation. We help customers set up their environments correctly, optimize their data pipelines, and ensure a smooth path to go-live. Beyond deployment, maintaining modern, up-to-date systems requires continuous effort—this is where ongoing health checks and proactive support become critical.
Confluent Platform, our on-premises version, is used at some of the highest scales globally, and the same holds true for Confluent Cloud. For instance, the platform powering large-scale events like the Cricket World Cup and the Cricket IPL has supported over 70 million concurrent users. This demonstrates the scale and reliability we can deliver across both environments. Ultimately, the choice between on-premises and cloud comes down to the skills available within the organization and their operational preferences.
Interestingly, India stands out as a market with exceptionally strong technical capability. We see a deep level of expertise in Kafka and Flink, more so than in many other regions. While organizations here value manageability, upgrade support, and access to new features, they also bring a high degree of technical proficiency to the table.
In terms of go-to-market (GTM), how is the structure in APAC, and what are the key initiatives you would like to highlight?
We view APAC not as a single market, but as a collection of distinct geographies. Within this landscape, India stands out as one of the most important markets. This is driven by several factors: its large population, the rapid pace of digital adoption, and strong uptake across sectors such as digital-native companies, banking, and telecom.
Today, we are seeing adoption of Confluent across virtually all major industries in India. From a GTM perspective, what excites us is the evolution of customer journeys. Most customers begin with Kafka, but increasingly, they are moving towards adopting the full data streaming platform. In India, this shift is happening at scale.
While this trend initially took hold among digital-native companies, we are now seeing banks in India adopt these capabilities at a pace that is faster than most global counterparts, with the exception of a few large institutions. Importantly, much of this adoption is being supported through Global Capability Centers (GCCs) in cities like Bangalore, Pune, and Hyderabad.
A key GTM initiative for us is our continued investment in India, including the launch of our Global Competency Center (GCC) initiative. Through this, we are focusing on engaging deeply with teams operating within India, while also influencing decision-making at their global headquarters.
Notably, GCCs today are no longer just execution centers. They are increasingly becoming decision-making hubs for global organizations. We are seeing both strategy and execution being driven from India, particularly for projects related to AI competency.
As a result, many of these organizations are actively evaluating the Confluent platform as a foundational layer for their AI and digital infrastructure.
Is the GCC shift no longer limited to moving support functions for global customers?
Today, these centers are actively driving decision-making for global markets from cities like Bangalore, Pune, and Hyderabad.
It is no longer a model where decisions are made overseas and execution happens in India. Instead, both decision-making and execution are increasingly co-located here, particularly for specific projects around AI competency.
In this evolving landscape, many organizations are also considering the Confluent platform as a core component of how they approach their AI and digital infrastructure.
When you look at India as a market, what does your GTM structure look like? How is it structured?
Our go-to-market in India is structured across two primary dimensions: geography and industry.
From a geographic standpoint, we have focused coverage across key regions — North, West, and Bengaluru as a major hub. Layered onto this is a strong industry lens. We align teams by verticals, with digital native businesses treated as a distinct industry given their scale and prevalence in India. Beyond that, we focus on key sectors including government, BFSI, telecom, and manufacturing.
Additionally, we have built specialized capabilities around data streaming, enabling us to go deeper into customer use cases within each of these segments.
Over the next few quarters, what will be your key focus areas across geographies, sectors, and evolving customer conversations, especially with digital teams and digital offices?
Digital native companies are currently at the forefront of adopting Confluent Intelligence, with BFSI close behind. However, BFSI presents a different flavor to it due to its inherent complexity.
Looking ahead, our go-to-market approach will continue to evolve. One of our biggest areas of investment is in building out our GCC presence in India, where we see significant growth potential.
From an industry perspective, we believe the government and public sector will become an increasingly important focus area. As part of our integration with IBM, we are working closely to strengthen our alignment with government organizations and government sectors. For instance, systems like UPI are underpinned by Confluent in various capacities. While not all of these deployments are publicly referenceable, they highlight the critical role we play in large-scale digital infrastructure.
We are investing deeply in India and continuing to, both technical and sales, and working closely from there.
IBM already has a large existing relation with many of the large customers, how does Confluent plan to leverage that?
The biggest advantage is distribution. IBM already has deep, established relationships at the C-suite level, especially with CIOs and senior decision-makers. These leaders are actively being consulted on how to expand and evolve their digital platforms.
The key for us is to leverage that existing presence. IBM is already in the room and part of these strategic conversations. For us, gaining access to those same conversations would otherwise require significant effort and time. By working closely with IBM, we can effectively participate in and contribute to these discussions without having to build that access from scratch.
