Breaking systems down: New York engineer connects laptop-speed analytics to the cloudFrom BNP Paribas to STOIC to MotherDuck

Profile / Data Infrastructure

Yves Le Maout and the Small Distance Between a Laptop and the Cloud

He learned to make risk systems dependable, led a remote analytics team, then helped put DuckDB in the cloud. Yves Le Maout's career is a study in making ambitious systems feel close at hand.

On a February afternoon in Brussels, Yves Le Maout stood beside a projection of two query plans. One branch stayed local. Another reached into the cloud. The diagram looked almost modest, a few boxes and arrows under the title “Hybrid Execution.” Its question was anything but modest: if a database already runs splendidly on your laptop, what exactly should happen when you connect it to a cloud?

Le Maout and fellow MotherDuck founding engineer Boaz Leskes had come to DuckCon in 2023 to answer that question in public. DuckDB was built as an in-process analytical database. It lived close to the user, close to the code, close to the machine doing the asking. The cloud offered persistence, sharing, and more room to work, but it also threatened to turn that immediacy into a round trip. Their proposal was not to choose one side. It was to teach both sides to cooperate.

Yves Le Maout presenting MotherDuck at DuckCon 2023 in Brussels
Le Maout at DuckCon 2023. The slide deck asked the serious questions; the laptop stickers kept the proceedings properly duck-adjacent.

This is a useful place to begin the story of Yves Le Maout because his career has been a long negotiation between hard systems and the people who need them to behave. Before the ducks and their excellent branding came financial risk feeds, a progressive analytics product, a remote engineering organization, and years of learning that infrastructure earns trust one reliable result at a time.

The risk feed does not care about your feelings

Le Maout studied two subjects that make an unusually compatible pair: computer science at ENSEIRB-MATMECA and financial and economic risks at Université Montesquieu Bordeaux 4. One asks how a system works. The other asks what happens when it does not. He finished both programs in 2009 and went into the Prime Brokerage IT team at BNP Paribas.

The titles chart a quick accumulation of responsibility. He began as a financial-risk IT engineer, became a technical leader, and then served as an assistant vice president. His work included stabilizing and optimizing a risk-feed platform and implementing real-time feeds. These are austere verbs: stabilize, optimize, implement. They belong to a world where the romance of software ends precisely when the market opens.

Risk infrastructure also offers a stern education in time. Yesterday's answer can be perfectly calculated and completely useless. A delayed feed is not merely slow; it changes the decision a person is able to make. Le Maout's later work would move away from prime brokerage, but it kept circling the same compact: data systems should be quick enough to meet the question and dependable enough to deserve the answer.

13+years from first finance role to MotherDuck's founding year
9years building and leading engineering at STOIC
2graduate fields: computer science and financial risk

A bigger product, then a bigger job

At the end of 2013, Le Maout joined STOIC, also known as Sutoiku, as a software engineer. “Full stack” can be a woolly phrase. His version was specific: Node.js and C++ on the server, AngularJS in the browser, DevOps, data curation, and service integrations. It was less a stack than a small city, and he learned the streets well enough to be appointed CTO and vice president of engineering in 2017.

The promotion did not seem to make him less technical. Olivier Gaucher, who worked beside him for more than four years, described a leader who could run a fully remote team, improve processes and tooling, challenge specifications, and still jump into a problem when somebody was blocked. “He embraces any challenge with confidence,” Gaucher wrote, praising how quickly Le Maout learned and how readily he shared that knowledge.

Brendan Colloran, a fellow member of STOIC's executive team, remembered a product with enormous technical and functional breadth. To lead it required both altitude and depth: keeping a team productive while getting specific, very quickly, when a new subject demanded it. That description catches an important tension in engineering leadership. The job asks a person to see the entire system while remaining useful inside one troublesome corner of it.

Think outside the box - Passionate about technology - Problem solving addict.Yves Le Maout, in his public profile

The phrase “problem solving addict” is slightly mischievous and more revealing than a solemn paragraph about excellence. Addicts return. They are not satisfied by having once solved a problem beautifully. STOIC gave Le Maout nearly nine years of returns: new technologies, shifting requirements, a distributed team, and a product ambitious enough to keep producing fresh corners.

Financial-risk engineering at BNP Paribas
Joins STOIC as a software engineer
Becomes CTO and VP of Engineering
Joins MotherDuck as a founding engineer
Co-authors MotherDuck's CIDR architecture paper

The useful middle between here and there

MotherDuck began in 2022 with an appealingly contrarian observation. Much of the data industry had spent years preparing for gigantic workloads. Meanwhile, modern laptops had become powerful, DuckDB had made local analytics remarkably fast, and many everyday datasets were not gigantic at all. Shipping every question to a distant cluster could be extravagant in cost, complexity, and time.

Yet local computing has clear limits. A laptop is not naturally a shared database. It may not have the memory for a larger job. It goes to sleep, gets carried onto airplanes, and occasionally meets coffee. The cloud is excellent at persistence, collaboration, and elastic resources. MotherDuck's bet was that the interesting architecture lived between the two.

The architecture Le Maout helped build gives each user a variable-sized cloud container running a DuckDB instance, cheerfully called a “duckling.” Storage sits apart in object storage. On the other end, the client still has DuckDB, including a browser client running through WebAssembly. A query may run locally, remotely, or partly in each place. The division depends on where the data sits and which machine is better positioned to do the work.

The important detail is not that the system can use two computers. Plenty of software can do that. It is that a DuckDB user can open MotherDuck without abandoning familiar queries. The 2024 CIDR paper that Le Maout co-authored describes the goal plainly: connect existing DuckDB users to cloud computing while preserving the experience that brought them to DuckDB in the first place.

Good infrastructure frequently hides a complicated negotiation behind a simple gesture. In this case, the user issues SQL while the system decides where that SQL should live. The local machine is no longer treated as a thin terminal, and the cloud is no longer treated as the only respectable place for computation. Both become resources. The ideology gives way to scheduling.

Cadence is a form of care

When a MotherDuck colleague left the company in 2024, he posted a roll call of teammates and their memorable associations. Next to Le Maout's name appeared a parenthesis: “release train!” The nickname is affectionate engineering shorthand. A release train is cadence made operational. Many people's changes board it. Dependencies must arrive in order. Somebody must keep the movement legible.

It also fits the colleague testimony from STOIC. Le Maout's technical breadth mattered because it helped other people move. His attention to hiring, process, tooling, and specifications mattered because difficult products are social systems wearing code. An engineer who can solve a problem is useful. An engineer who can make a team better at solving the next one compounds.

There is a pleasing symmetry here. Hybrid query processing coordinates local and remote resources without pretending they are the same. Engineering leadership coordinates people with different specialties without reducing them to interchangeable compute. In both cases, the work begins by understanding what is already present, then routing the problem with some care.

His public interests add a quieter clue. Le Maout lists photography alongside computer science. A camera rewards attention to the frame: what belongs inside, what can stay outside, where the light already is. Database architecture is not photography, however tempting the metaphor, but both punish the urge to include everything merely because it is available. The hybrid system's elegance comes from refusing unnecessary movement. Some data can remain here. Some work belongs there. The achievement is not sending more; it is seeing the boundary clearly enough to send only what helps.

Le Maout's path from Paris finance to New York data infrastructure does not require a mythic reinvention. It reads more like an expanding definition of reliability. First a feed must arrive. Then a product must keep working as its surface grows. Then a remote team must deliver amid change. Finally, a database must decide whether the shortest route to an answer passes through the laptop, the cloud, or both.

Back in Brussels, the hybrid execution slide made the architecture look almost obvious. That is usually a compliment. Simplicity in a finished diagram is evidence that somebody spent time wrestling the complexity elsewhere. Le Maout has made a career of going elsewhere, into the feed, the stack, the team, or the query plan, and returning with fewer boxes than he found.