Dwight Merriman and the art of keeping the useful part

A database is an unusual souvenir to bring home from ten years in advertising. Its origins lay in the jobs Dwight Merriman had spent years doing. At DoubleClick, he had helped build the machinery that delivered advertisements across the web. Keeping it running meant confronting the awkward distance between the software available and the software an expanding internet business needed. Years later, he helped create MongoDB, a database shaped by that distance.

There is a temptation to tell this as a tidy sequence: spot a problem, found a company, release the answer. Merriman’s route had considerably more furniture in the way. The company that became MongoDB originally intended to offer an entire platform for building and running applications. The database was a component underneath. Eventually, the component got the company to itself.

That change is a useful place to begin. Merriman’s career has involved building large things, but one consequential decision involved making a plan smaller. Ambition can occupy every room in a startup. Occasionally, somebody has to open a window.

A basement, a browser, and two Kevins

Merriman started working with computers at 14. He later earned a B.S. in Systems Analysis and Computer Science at Miami University. The technical interest preceded the executive titles. Software was already something he wanted to work on, before there was an internet advertising business for him to help invent.

In Atlanta, he worked at DCA, where an R&D group led by Kevin O’Connor encouraged him to think about new products and businesses. The arrangement matters: his introduction to entrepreneurship included experimenting inside an existing organization. A new idea did not have to arrive wearing a startup’s name badge.

O’Connor became his partner in DoubleClick, which began in O’Connor’s basement in an Atlanta suburb before relocating to New York. Merriman co-founded the company in 1995 and served as its chief technology officer for ten years. The basement belongs in the story, although the more revealing part is the decade of work that followed it.

He designed DoubleClick’s original DART technology, short for Dynamic Advertising, Reporting, and Targeting. Behind the advertisements sat a demanding engineering operation. Merriman later described thousands of servers and a dozen data centers around the world. A system could be geographically scattered and still have the intensely local problem of one person waiting for one page.

DoubleClick was sold to Hellman & Friedman in 2005 for $1.1 billion. Google subsequently acquired it for $3.1 billion in 2008. Those are separate transactions. Merriman’s technical tenure belongs to the earlier chapter; the later acquisition put the business he had helped create inside Google.

After DoubleClick, another Kevin became a recurring collaborator. Kevin Ryan had been its president and CEO. Together, Ryan and Merriman helped establish a collection of New York businesses through AlleyCorp. The ventures included Business Insider, Gilt Groupe, ShopWiki, and MongoDB. News, fashion, shopping, and databases make an eclectic dinner party.

The common thread was the working relationship. Merriman brought engineering experience; Ryan brought experience building and running businesses. Eliot Horowitz, another DoubleClick veteran, became MongoDB’s technical co-founder. The next company emerged from people who had already seen one another solve difficult problems.

The useful part survived

They founded 10gen in 2007. Its initial platform would help developers build and run applications, with MongoDB as the internal data layer. The plan was broad enough to encompass much more than a database. It also arrived as cloud computing was making new kinds of infrastructure possible.

Then Google introduced App Engine. Merriman reconsidered the scope during a family vacation: the larger platform would require more time and resources than he thought a startup could reasonably obtain. Users had responded well to the database. He proposed concentrating on that piece.

Horowitz considered the proposal and agreed. Ryan supported the technical founders’ judgment. The team discarded the application layer, reduced staff, and built drivers so other programming languages could use the database independently. A change in strategy had consequences for actual people and actual code.

The choice deserves its uncertainty. Beta users had liked the broader product. Giving it up meant surrendering something that might have worked. The founders proceeded anyway. MongoDB became publicly available in 2009; in 2013, 10gen adopted the name of the product that had become its business.

A database with room to change

The name came from “humongous.” The engineering question was more precise: how could a database accommodate growing applications without making developers repeatedly rebuild the infrastructure around it? Merriman and Horowitz had lived with those workarounds. Horowitz later counted roughly a dozen custom databases between them in the decade before MongoDB.

A document model offered a way to store related information together and accommodate changes in its shape. For a developer, the attraction included a closer fit between the data an application handled and the data it saved. Growing across multiple machines was another central concern. A database needed to be usable at the keyboard and manageable across the system.

Merriman’s early technical explanations acknowledged choices rather than promising universal victory. Relational databases were powerful, familiar tools. Moving away from them required a reason. He emphasized scaling and development agility, while arguing that some features could make distribution harder.

“distributed joins are hard to scale.”

Dwight Merriman, 2011

That observation concerned the work of combining data across machines. It gives the design debate a concrete center: what happens when a feature requires separate parts of a system to coordinate? The interesting argument is about the cost of that coordination, and how much a particular application needs it.

Merriman expected companies to use different stores for different jobs, including relational databases, NoSQL databases, and data warehouses. It was a plural view of the future. A database founder could believe in his own tool without requiring the rest of the toolbox to disappear.

The CEO who wanted time to code

Merriman was MongoDB’s first CEO. That role put a programmer amid hiring, funding, and coordination. By 2014, he described an ideal working arrangement that would leave a third of his time for coding. Anyone who has watched a calendar swallow an afternoon can appreciate the specificity of that wish.

His interests remained close to the work itself. He urged developers to explore areas beyond their personal interests, reasoning that attachment to a hobby could make it harder to judge a business objectively. The advice fits the decision to narrow 10gen: affection for an idea and evidence for pursuing it require separate consideration.

In discussing fundraising, he returned to happy users, customers, and a durable business. Hiring and retaining capable people demanded sustained attention. Product maturity would take years, with more work on performance, parallelism, and making large systems easier to operate. A financing announcement could happen on one day; the engineering obligations would be waiting the next morning.

The practical ambitions were consistent with the early product. Giving developers an accessible way to begin could help a tool spread. Keeping it useful as their applications grew was a longer commitment. Merriman spoke about startups and large enterprises using the same database, audiences whose budgets and operational needs could differ considerably.

Small annoyances, carefully considered

His personal blog supplies a quieter portrait. There are posts about BSON, the binary document format associated with MongoDB, and utilities for handling those files from the command line. He also published a separate C++ BSON library, exploring its usefulness beyond a database.

Then there is Gmail. He questioned a redesign that replaced text buttons with icons: could people readily tell which meant archive, spam, or move? Even a person accustomed to complicated systems could object to an everyday task acquiring a guessing game. An envelope should not need a seminar.

Elsewhere, he argued for readable names in C++ and examined whether phone navigation made expensive built-in car systems less attractive. The topics are modest in scale, but the attention is recognizable. He keeps considering the person using the tool, the surrounding constraints, and whether an established arrangement still earns its place.

A founder’s biography often expands until every preference becomes a philosophy. These posts can remain small observations. Their charm lies partly in that size: a programmer thinking aloud about ordinary software, with room for irritation and a joke.

Another kind of endurance

In 2018, Merriman began competitive racing in a Volkswagen Golf. His later racing record included Era Motorsport and the Rolex 24 at Daytona. In 2021, he shared an LMP2 class victory there with Kyle Tilley, Ryan Dalziel, and Paul-Loup Chatin.

He shared another Daytona LMP2 victory in 2024, this time with Dalziel, Connor Zilisch, and Christian Rasmussen. At Sebring that March, Merriman, Dalziel, and Zilisch won the LMP2 class again. These were class victories in races with several categories competing together, achievements belonging to the crew and its drivers.

By July 2024, Era Motorsport said Merriman was looking toward a different racing project. Its March 2026 announcement named him alongside Jake Hill, Dalziel, and Oliver Bryant in the No. 81 Ferrari 296 GT3 for the European 24H Series. Another vehicle, another shared assignment.

MongoDB’s current board biography identifies Merriman as director and co-founder, serving on the board since July 2020 after an advisory role. Stockholders re-elected him in June 2026 for a term running to the 2029 annual meeting. His career now contains both the company he helped start and a racing calendar. Neither chapter needs to explain away the other.

The through line remains visible without turning it into a slogan. He worked with colleagues, encountered the limits of existing tools, and helped build alternatives. When a larger plan became difficult to justify, he kept its useful part. A database survived the decision. So did the programmer’s interest in what could work better.