Ask Sijie Guo to explain the plumbing of the internet and he may take you to a bank. A customer waits for a teller. Someone gets served. The next person moves forward. This, he explains, is a useful way to understand a message queue: work arrives, waits its turn, and gets handled. For a subject capable of clearing a dinner table in seconds, it is a considerate opening.
Then he changes the example. Imagine a sensor recording temperature. Each reading belongs to a sequence; its position matters if you want to understand what changed. That is streaming. The distinction has occupied a substantial part of Guo’s working life. Systems need to distribute jobs, preserve histories, and make information available while it is still useful. The everyday appearance of a notification conceals a rather demanding delivery service.
Guo, the co-founder and CEO of StreamNative, has worked on that service at Yahoo and Twitter, helped start two companies, and remained involved in the Apache software community. His career offers a view of entrepreneurship from the basement machinery room. The question running through it is practical: how much of the infrastructure built inside enormous internet companies can other organizations actually use?
Before the pitch, the push notification
At Yahoo, Guo worked on push notification infrastructure and the global messaging work that became part of his history with Apache Pulsar. At Twitter, he led the messaging infrastructure group and co-created DistributedLog and Twitter EventBus. These are jobs concerned with whether information arrives intact, in the right order, and where it belongs. A missing message is a small item with a talent for becoming someone else’s large problem.
DistributedLog’s design separated the service doing the work from the storage preserving the records. Its documentation describes scaling storage independently of CPU and memory. That separation matters because an application’s appetite for computation and its appetite for keeping data do not necessarily grow together. Buying more of both whenever one becomes scarce is an expensive habit.
The project’s authors included Robin Dhamankar, Guo, and Leigh Stewart. Their work also became a 2017 conference paper. Guo’s technical history has this recurring feature: software built for operating systems at scale also becomes something to explain, document, and expose to scrutiny. The code has colleagues, users, and an argument behind it.
A company is another kind of distribution problem
Guo co-founded Streamlio in 2017; Splunk acquired it in 2019. StreamNative followed in 2019. The new company’s proposition was to make enterprise messaging, particularly Pulsar, easier to use in the cloud. An organization could want the capabilities of a large internet platform without wanting to assemble a department to operate the underlying machinery.
By September 2021, Guo was describing a different stage of the job. StreamNative had launched its cloud offering in mid-2020, attracted customers, and was raising money to expand product development, marketing, and sales. The company’s Series A totaled $23.7 million. A distributed system needs capacity; a company needs people who can help someone decide to buy it.
His explanation of the customer’s problem was similarly concrete. Static data already had well-developed tools. Data in motion brought a changing load, demanding systems that could grow or shrink with incoming traffic. The difficulty lived in the fluctuation. Capacity that looked sensible yesterday could be insufficient tomorrow or sit idle at considerable expense.
That commercial turn also changed Guo’s own work. He has described moving toward go-to-market strategy and helping shape the company’s bring-your-own-cloud offering with customers. In that model, the service operates within a customer’s cloud environment. The architecture has to accommodate the buyer’s concerns about control as well as the engineer’s concerns about throughput.
The room needed more tables
There is a photograph from Pulsar Summit San Francisco 2022 in which the software community becomes pleasantly literal. People fill rows of tables, laptops open, facing a stage. Guo and StreamNative CTO Matteo Merli presented on microservices and event-driven applications. The event sold out; organizers added tables. Open source, occasionally, requires furniture.
More than 200 people attended, alongside speakers and participants working with technologies including Beam, Pinot, Flink, Hudi, and Delta Lake. The program extended beyond Pulsar itself. That detail helps explain the kind of company Guo is building: its usefulness depends partly on how well its technology fits into work already happening elsewhere.
His Apache responsibilities have included serving as BookKeeper’s project chair and vice president, an office he left in June 2023. He is also a Pulsar project management committee member. These roles place him in the shared maintenance of software whose community extends beyond his company. A product roadmap and a public project have overlapping constituencies, each capable of asking awkward, necessary questions.
Learning to speak Kafka
Guo’s public writing can be competitive. After attending Confluent’s Current conference in 2023, he examined Kafka’s queue semantics, infrastructure costs, and the case for bring-your-own-cloud deployments. He paid particular attention to customers running many clusters and leaving capacity underused. His interest in a rival’s conference was specific: what were users still struggling to operate or afford?
That attention accompanied an expansion into Kafka compatibility. StreamNative introduced Ursa in 2024, giving customers a Kafka-compatible streaming engine. Guo’s company continued to work on Pulsar while meeting developers through an interface many already used. Technical preferences are one thing; asking a customer to replace familiar tools is a separate negotiation.
In February 2025, Guo and David Kjerrumgaard argued for bringing streaming closer to the lakehouse, where organizations keep data available for analytical work. They emphasized open formats, catalogs, and engines. Those words describe a division of labor: agree on how data is stored and governed, then let different tools work with it. Fewer custom bridges would mean fewer bridges to maintain.
“our idea is quite simple and straightforward”
Sijie Guo, on the thinking behind StreamNative
The bill becomes part of the design
In September 2025, the Ursa paper received the Best Industry Paper award at the Very Large Data Bases conference. Guo shared authorship with Matteo Merli, Penghui Li, Hang Chen, and Neng Lu. The recognition attaches to a team and a specific piece of work: a streaming engine designed around cloud object storage and open lakehouse tables.
The paper starts with an unromantic observation. Keeping streaming and analytics in separate infrastructures can mean copying data, maintaining connectors, and paying for traffic between cloud availability zones. Those activities may be necessary in a particular design, but their cost still appears on the bill. Cloud architecture has a way of making the accountant an involuntary design reviewer.
Ursa changes where the records live and how the system accesses them. The paper reports infrastructure expense reductions of up to tenfold in its experiments. That is a result under evaluated conditions, rather than a promise about every customer’s bill. Its significance for Guo’s story is the choice of problem: the team treated cost and operational work as engineering questions deserving a redesign.
VLDB 2025 Best Industry Paper
Guo · Merli · Li · Chen · Lu
The new agents have an old coordination problem
As AI agents entered the company’s agenda, Guo returned to a familiar concern. In April 2025, he described a hypothetical organization deploying separate agents for support, sales, and operations. Each might be capable within its own assignment while remaining unaware of what the others had learned. Automation could create a new clerical job: carrying information between the automated workers.
His proposed remedy drew on event-driven systems. Shared streams could give agents current context and a way to coordinate. The example is illustrative, rather than an account of a named customer. It reveals how Guo approaches a fashionable topic through a problem he has worked on for years: how separate pieces of software exchange information without producing a tangle of individual connections.
At the 2025 Data Streaming Summit, he predicted that real-time intelligent agents would become a standard part of enterprise operations. Later that September, his keynote conversation with Databricks co-founder Reynold Xin addressed open formats, governance, and the future of the lakehouse. His circle of technical discussion had expanded, while the subject of dependable, usable data remained close at hand.
Opening the storage room
On September 23, 2026, Guo, Merli, Li, and Chen announced that Ursa, Ursa for Apache Kafka, and the Lakestream API and specification were open source under Apache 2.0. The announcement proposed a shared storage foundation that different streaming systems could implement. The ambition now reached below the familiar messaging interfaces to the records themselves.
The distinction is consequential. Agreeing on how to send a request does not automatically let another tool read the stored data. The team’s argument was that streams needed an open storage contract, much as tables had benefited from shared formats. At release, the open build shipped with Kafka support; Pulsar support was described as coming. The wider design was still work in progress.
For Guo, this extends a career spent moving between running systems, explaining them, and building a business around their use. His favorite milestones include early users successfully putting open-source software into production. There is a modest test embedded in that memory. Someone else has to trust the machinery enough to depend on it.
The bank queue remains a useful place to leave him. An ordinary person wants something handled; a complicated system must cooperate to handle it. Guo has spent years working through the distance between those two facts. The message gets delivered. Ideally, nobody receiving it has to learn how much engineering that required.