Snapchat paid for the ride. Uber got the engineer. While interviewing with Snapchat, Vinoth Chandar received a coupon for an Uber to its Venice Beach office. The service caught his attention. He eventually chose Uber, drawn to the chance to build a company’s data architecture while much of it was still unwritten. Recruitment budgets do occasionally produce unexpected returns.
The appealing part was the responsibility. Here was a growing business whose movement through the physical world depended on information moving through computers. Someone had to make that information arrive, remain useful and survive the company’s expansion. Chandar wanted a substantial part of that job.
Years later, he would create Apache Hudi at Uber and found Onehouse. There is a straightforward way to tell that story: engineer builds software, software attracts users, engineer starts company. It leaves out the more interesting question that followed him between employers. Why did the next team have to build so much of the same machinery again?
01An education in things going wrong
Chandar studied at Madras Institute of Technology, part of Anna University, before pursuing graduate study at the University of Texas at Austin. His early work included software for a student satellite’s telemetry controller. A satellite is an exacting introduction to distributed computing: the other computer is inconveniently located, and a casual request to restart it has limited appeal.
His professional education continued inside databases. At Oracle he worked on streaming and replication, the business of carrying changes from one system to another. Reliability has a different meaning when someone’s records depend on your code. A feature that works under friendly conditions is only the beginning. Releases, recovery and the troublesome cases determine whether people can rely on it.
LinkedIn brought him into Voldemort, the company’s distributed key-value store. The name offered a little theatrical menace; the work involved ordinary, consequential obligations. Keep the service available. Make it perform. Help the rest of the company use it. Chandar became the project’s lead, working on the kind of shared infrastructure whose successes tend to disappear into other people’s products.
A colleague’s public recommendation supplies a useful glimpse of how he worked later at Uber. Aaron Schildkrout remembered both the architecture and the late troubleshooting sessions. He called Chandar “a real systems thinker” and “a terrific team player.” The pairing matters. A system diagram can be a solitary accomplishment. Getting a company through its inherited bugs takes company.
02The lake learns to change its mind
At Uber, the problem took a particular shape. Large collections of data were useful for analysis, but the business kept changing underneath them. Records arrived late. Existing information needed correction. New data needed to feed other datasets. Cheap storage alone could not supply all the behavior people expected from a database.
Hudi addressed that gap. Created in 2016 and open sourced in early 2017, it brought updates, deletes and incremental processing to the data lake. The original name spelled out the agenda: Hadoop Upsert Delete and Incremental. Pronounced “hoodie,” it was a fairly comfortable name for software doing rather uncomfortable work.
The crucial idea is understandable without a computer science degree. If part of a collection changes, process the changes rather than repeatedly treating the entire collection as new. Preserve the ability to update a record. Make the resulting data available to the engines people already use. Those requirements become difficult when many jobs, files and machines are involved.
The original Uber design also allowed several query engines to work with the data. That choice placed Hudi inside an existing ecosystem. Users could keep different tools for different jobs while sharing a data layer. It is an architectural preference that would keep resurfacing in Chandar’s work.
Hudi subsequently became a top-level Apache project in May 2020, with Chandar appointed chair. By June 2026, its board report recorded 43 committers and 20 project management committee members. An internal solution had acquired an independent community, release obligations and a life extending well beyond the company where it began.
03A company built around the chores
Chandar also worked at Confluent, adding streaming systems to a career already spanning several kinds of databases. By the time he introduced Onehouse publicly in February 2022, he had spent years seeing what happened between a promising piece of software and a dependable service. Plenty could happen in that interval. Very little of it belonged in a launch demonstration.
Onehouse’s founding argument concerned that interval. Engineering teams could download sophisticated open source tools and still face months of assembly and operation. Ingestion had to work. Files needed managing. Tables needed optimizing. Failures needed attention. Possessing the components left a substantial amount of work on the buyer’s desk.
The company launched with an $8 million seed round from Greylock and Addition. Jerry Chen, the Greylock partner who worked with Chandar while Onehouse was still an idea, described a founder thinking about how experience inside Uber could translate into customers’ problems elsewhere. The experience was useful precisely because most customers were trying to avoid reproducing Uber’s engineering investment.
“Back to building…”
Vinoth Chandar, closing his February 2022 launch post
The launch post ended with a personal detail beneath the product explanation. Chandar thanked investors for supporting him through an eighteen-month effort to obtain his green card. He had contributed nights and weekends to the community while on a work visa. Being able to work full-time on Hudi and data lakes mattered to him. The terse closing line carried the relief of finally getting on with it.
In June 2024, Onehouse announced a $35 million Series B led by Craft Ventures, with Addition and Greylock participating. Funding gave the company more capacity to pursue the operational work. It also sharpened the commercial question: what, exactly, was a customer paying Onehouse to take responsibility for?
04The right to leave
The answer required some boundaries. Hudi belongs to the Apache Software Foundation’s governance system. Onehouse contributes to it and builds commercial services, but the company does not own the project. For a founder whose identity is closely tied to the code, accepting that separation is a consequential business choice.
The chair’s role places him in two working worlds at once. One has a company roadmap, customers and investors. The other has contributors, public releases and accountability through a foundation. Progress in one can help the other, but neither job makes the other disappear. The distinction is easy to compress in a biography and harder to maintain in practice. It is part of what makes his move from engineer to founder more complicated than a change of title.
At launch, Chandar also described a route away from the managed service. A customer that developed its own operating team, or needed to bring operations in-house, should be able to move to self-operated Apache Hudi. The right to leave gives a particular meaning to the promise of openness. It makes portability relevant after adoption, when moving has become inconvenient.
This is where his engineering argument becomes a commercial one. Customers want less operational work. They may also want the freedom to change engines, providers or arrangements later. A service has to earn its place through the work it performs while preserving enough choice for the customer to reconsider. That is a demanding proposition to keep as a platform expands.
Chandar has been candid about another difficulty: explaining the work. In a 2024 conversation about open source businesses, he discussed having spent too little time educating people about Hudi’s capabilities, allowing other players to shape the narrative. Technical breadth does not explain itself. A founder can be busy solving a problem while someone else supplies the vocabulary customers use to understand it.
at Uber
project established
public launch
05Choosing which arguments to have
The product kept widening. In May 2025, Chandar co-authored the announcement of Spark and SQL workloads powered by Onehouse’s Quanton execution engine. His review of that year returned to a familiar concern: teams could choose open formats and still struggle with costs, metadata and unpredictable performance. Adopting the architecture did not finish the operational job.
In July 2026, a smaller decision revealed something about the allocation of effort. Onehouse’s LakeBase name overlapped with Databricks’ Lakebase. Chandar explained that the companies had not converged on the issue, and Onehouse would rename its product Lakegres. A smaller startup could spend years litigating a word. It chose to ship. Naming is one of technology’s few problems that can remain expensive after all the code works.
By September, his attention included AI agents. Onehouse announced an AI Gateway combining model routing and tool access under shared controls. The interface to data was changing again: software agents could issue queries and call tools at machine speed. Questions about permissions, observability, cost and where the data lived followed them. Chandar’s answer extended the platform toward those responsibilities.
He reserved plenty of argument for other subjects. In October 2026, he publicly challenged why major warehouses continued to favor closed-format defaults despite their open-format announcements. The contention was his, and he pressed it as a question of customer choice. His willingness to argue about the default setting fits the rest of the career: architecture becomes consequential at the point where someone has to live with it.
The Uber coupon makes an entertaining beginning. The work after the ride gives the story its shape. Chandar has kept returning to changing data, the people responsible for it and the effort that disappears between a technical idea and its daily use. Onehouse is his attempt to sell that missing work as a service. The question he is carrying forward is plain enough: how much should the next team have to do all over again?