Cedric Villemain

Can you introduce yourself and tell us a bit about your background?

My name is Cedric Villemain. I'm turning 50 this year. I'm a family man, married, life is good. And I work in IT.

I got into computers very early. I was lucky because I went to a school that had a computer when I was in first grade, so around age 5. I did Logo on an Apple II at 5 years old, that old thing with the little turtle you moved around, the first algorithmic tool for kids.

In middle school, I came back to the Apple II and did Apple Soft and Apple Pascal. Then Turbo Pascal, then C. I went through a lot of things in development over the years, while following a course of studies that wasn't necessarily focused on IT. I did some, but it was on the side.

My journey was realizing that IT was what I enjoyed most and probably what came most naturally to me. I really threw myself into it in my late twenties.

I did a program through AFPA because I wanted to move fast. I had missed the Internet bubble and wanted to get back into IT on a very short cycle, just to get in the door.

How did you end up in databases?

I got my first job in web, at a company called JFG Network, an obscure name for a company that ran a site called Overblog, one of the first major French blogging platforms. I was the first employee of that startup, which was really fun. I came in as a developer, around 2004 to 2007.

We faced major challenges, big projects with heavy loads. It ended up being a big deal: Médiamétrie called us asking us to agree to be counted in their ratings because we were disrupting their counters.

Those were great challenges and they pushed me to work with very large databases. We were on MySQL and had to move to PostgreSQL because we needed something more robust. I had the opportunity to work with Oleg Bartunov and Teodor Sigaev, the two PostgreSQL developers who now run PostgreSQL Pro.

The company I was at sponsored the completion of tsearch development in PostgreSQL, the full text search engine. For six months to a year, I worked with Teodor and Oleg to build a full text search engine for the site. Those were my first steps in the open source community, specifically the support for French-language vector search in PostgreSQL, around 2006-2007.

At the time, tsearch didn't support French. Since Overblog was in France with a lot of French content, I improved the stemmer and text vectorization mechanisms in PostgreSQL so we could index vector text with tsearch.

That's how I got into it. PostgreSQL and databases were for me a great bridge between the developer side and the operational side, plus the algorithmic, mathematical, logical aspects. With PostgreSQL, you can touch everything. If you only like SQL, you do SQL. If you like the operational side, you do that. I like touching everything.

How did you train yourself during that time?

I did take some theoretical courses at university: IT management, computer science fundamentals.

But the core of my knowledge and training came from learning on the job. When you're in a startup and you're taking hits, you're forced to react. Beyond that, it came a lot through social networks. Back then it was IRC, a great way to do Q&A and be involved on both sides, which helps you progress.

Then there's project documentation. PostgreSQL's documentation is so rich that it already lets you understand and go very far. And then the source code. People always say RTFM, but the source code, when it's well written, and PostgreSQL is well written, lets you see how things actually work. That helps a lot.

For most of the projects I use, before using them I'll quickly look at the source code just to get a feel for it. If it's written like a mess, it's not worth it.

What is Data Bene?

Data Bene is the commercial name for the company officially called ABCSQL. It's a PostgreSQL expertise firm. We're really focused on the notion of data: relational, graph, semantic. We aim to be in a project-oriented relationship with our clients. It's very often PostgreSQL, but not exclusively.

Data Bene grew out of the first company I founded, called 2ndQuadrant France, which was affiliated with 2ndQuadrant, a well-known name in the PostgreSQL community. We operated for about ten years doing consulting and R&D. We developed PostgreSQL extensions in France. If extensions exist in PostgreSQL today, it's partly because we built them here with Dimitri Fontaine. That's pretty cool.

After about ten years, the brand was sold. 2ndQuadrant was acquired and we had to change our name. We had the option to become a software publisher or something else, but we preferred to stay on an open source path with a services-driven dynamic, which matched our values. A broad, ecosystem-level approach is what defines us, what we've kept, and what I believe makes us strong today.

How big is the team at Data Bene?

It fluctuates, but we're around fifteen people right now. We can't hire as fast as we'd like to. Ideally we'd bring on one person a month on average. We should double in size within the year.

Do you have any open source projects you're maintaining?

We have a project called pg_benchmark, an audit solution. From a technical standpoint, there's no huge innovation. The key point is that it lets us collect information from our clients' servers and databases. It handles information system security, specifically classifying the data we work with. We work with hospitals on medical databases, for instance, and we can characterize whether we're allowed to access, read, or process certain data.

Beyond that, we mostly use what exists and propose innovations. I have an extension, pgfincore, that I've maintained for about fifteen years with great help from Christoph Berg, who maintains the Debian buildfarm for community projects and is a committer on pgfincore. Christoph also frequently provides fixes whenever a major PostgreSQL release introduces a regression.

But I don't consider these major projects; they're accessory tools in an ecosystem that has thousands of others. We prefer to position ourselves the way we were at 2ndQuadrant: really focused on development and R&D for Postgres. We're very active contributors to Citus Data and IvorySQL. That's what we aspire to.

And today as CEO, what does a typical day look like for you at Data Bene?

My day will sound scary. I do a lot of things that aren't PostgreSQL. I have to run a company, so there's sales, marketing, HR, etc. I tend to have long days. I get up very early.

Roughly from 5am to 7am, I do my review. Morning is quiet, almost nobody around. Sometimes as I have colleagues in Asia, it's a good moment to connect with them. After that it's very variable: lots of exchanges with colleagues on various projects, unblocking situations, strategic discussions around sales. But I try to spend a big chunk of my time on R&D, monitoring, and new development directions.

There are plenty of things I know how to do at this point, but plenty I no longer want to do. I'm really glad we've grown and that everyone has been able to take on more and more, taking things off my plate completely. That's great.

What advice would you give a young person who wants to join a database company?

PostgreSQL databases drew me in because they're very central, and that centrality let me touch all the surrounding elements they depend on to work well. And we're in a major era of change.

Data, information management, access and processing, all of that is becoming more important than it has ever been. The new agentic development models are exciting and will touch databases across multiple domains.

There's still an expertise, a control, a capacity to understand what's happening, and that's the interesting point. The ability to understand, to ask questions, to be critical. In databases, our expert perspective is often very critical because with SQL there are many ways to do something. There are multiple normal forms for a reason, because you can reach your goal by different paths. You need to be able to step back and look at things critically.

Maybe the best advice would be to develop your critical thinking and stay relevant. PostgreSQL is great. It's a relational database, very well built. Today it's also a graph database, a semantic database. If you want to be in innovation, it's a great place to be. If you want something purely operational and industrial, it's a great place to work too.

You've been active in open source for many years. What has been the impact on your development?

In terms of my professional career, it's led to an enormous number of things. My first job wasn't at an open source company, but I only stayed three years and after that I worked exclusively in open source. Even in those first three years, we were already on open source software.

For me, open source was mainly a great way to understand what was happening and to learn IT. A good lever not just for reading documentation to figure out how to use some tool that seems magical, but for understanding how the tool actually works.

When I left Overblog, I looked for work in open source because it seemed much more interesting to build tools that could keep improving without running into the same problems over and over again.

Do you remember your first contribution?

I think my first contribution was French-language support for tsearch in PostgreSQL. It was patched into the module in version 8.1 and I think it was integrated in 8.2.

A few years ago I started receiving little PostgreSQL contributor badges from time to time, which was cool. I've had the feeling of participating for 16 years. I was really happy to get those badges, though I don't make huge numbers of contributions in my own name.

What do you think about the future of open source?

I think that question has been settled for a long time. I'd be surprised if things evolved in a direction that reversed open source dynamics. As things stand, open source code is already hard to guarantee as reliable or well written. I don't think that confidence is going to increase for closed source publishers, and even they have almost entirely switched. When you look at the PostgreSQL codebase, it's solid.

Databases are probably the most omnipresent thing still in human hands, so to speak. The entire layer of interfacing between users and the information in databases is being handled with far fewer resources, fewer people, less brain power, and a lot is being automated.

But the database is what contains the information. How we authorize information to be shared, how we encrypt it, track it, authenticate it, ensure it's relevant at a given point in time. I think the reasoning mechanisms around data remain, and the database is the right tool for expressing that. I'd say we still have a long time ahead of us managing this.

Do you use AI in your day-to-day work?

Like many people I suppose, I started with ChatGPT. We had a company account, that was great. But for the past six months, the work I do runs on AI systems we administer directly on GPUs, not our own models, but open source models we use.

There's the classic chat side, which lets you do quick discovery, faster than Google. But there's also all the agentic development across different agentic strategies. At the developer level within the team, everything around code generation is clearly a massive time-saver, including doc generation.

A few years back when it was just starting, I put my pgfincore code into the chat and said go ahead, write me the docs. It wrote the whole thing, impeccable, the readme, all the technical content. It was so good that it had added an option that wasn't in the code yet but that I had wanted to implement.

That illustrates the thing. You still need to check quality. But it's very good, it's exciting, it predigests a lot of work.

There are real cognitive dangers in AI use depending on how it's used. MIT studies have shown that within a few months, you can see cognitive impact, not a permanent reduction in cognitive ability, but significantly less activation than before. There are also other efforts aimed at making AI stimulate learning rather than replace it, and that's part of the work we're doing.

Since we work with PostgreSQL, and PostgreSQL is the database of all AI, we cover vector databases, graph databases, semantic databases. At the same location you have historical relational data on one side, and all the new LLM needs on the other. We just have new key players in the database, heavy users with different requirements, and that brings new challenges. That's a big part of how I see it.

Do you think AI will replace junior developers?

Juniors specifically, I don't think so. A friend put it well using an agriculture analogy. He said: back when it was harvest time, you needed thirty people in the field and you had to be done by the end of the day. Then came the combine harvester. You went from thirty people to one. Now there are multiple harvesters in the field, guided by satellite systems, while the farmer supervises the operation and focuses on higher-level decisions.

The combine harvesters have arrived in the developer's field. A growing share of the work that consists of translating well-understood requirements into code and tests is being automated. In my experience, this has little to do with whether someone is junior or senior. It has more to do with what motivates people, where they find fulfillment, and the kinds of problems they enjoy solving.

People who primarily enjoy implementing solutions may find that their day-to-day work evolves. People who enjoy understanding why those lines of code exist, why those tests are there, what trade-offs are being made, and how a system should behave still have plenty of work ahead of them, whether they're juniors or seniors.

AI can generate code, but it doesn't yet provide the broader perspective, judgment, and critical thinking that software development often requires. Those remain necessary, and likely will for quite some time.

Has AI changed how you work?

The impact on work is that there are many things we'll no longer need to write, think through, or reason about ourselves. We'll be much more focused on formal approaches. We're going back to fundamentals that we may have let slip a bit in IT.

When I started, we talked about methods, UML, a lot about formulations and specifications, things that are actually major drivers of progress with the agentic world. You need to train people in IT to use these tools well. But it's easy to consume them just for copy-paste.

On the database side, I'm fairly confident. On the developer side, it's different. We see it clearly at Data Bene in the requests coming in from dev companies, in India but not only India, where they had huge coding capacity. The job is fundamentally changing, the engagements are different, because it's a trade that's being disrupted.

How could a junior developer counter that?

Maybe we need to go back to the analyst-programmer world, I'm not sure. But yes, that's kind of it: the analyst side. Soft skills, definitely.

Managing our projects well, deeply understanding what we want to build or what the people behind our projects and products want to get out of them, and being able to transmit that clearly, put it on paper. That's going to matter.

I had planned to give a talk in China explaining to developers how to add a feature to PostgreSQL and IvorySQL, specifically what the steps were. But now you just ask a reasoning-capable LLM, you give it the source code, and in five minutes it's unpacked the whole thing, given you the full stack, explained how it works. And it's all correct.

I'm not going to have people sit through an hour talk on something they'll have the answer to in three minutes the day they need it. Full-stack web devs probably have more to worry about if their main job was PHP or Node.js. But there's a whole world of development that still exists, thankfully.

What's the best piece of advice you've ever received?

I talked about it with my wonderful wife. She gave me the French version, but I've kept the English one. It's pretty much "Just do it."

It's advice that has helped me and kept coming up at moments in life where there were choices to make and you think, do I do this or not. At some point you just have to do it to find out if it works. If you want to know whether something is possible, you do it and you'll see.

And what's your own advice for young people?

If you believe it's possible, do it. My advice would be to go where you think it's worth going. I'm 50, but the years go by fast. If you wait to do the things you want to do, you might not get to them.

A good way to do what you want is to tell yourself "I can get there, I can do this, so I'm going to do it." Once it's decided, you make it work.

But for something a lot less philosophical, I'd say: keep your critical thinking, don't swallow things whole, systematically question things. There's the umbrella theorem, which illustrates that things aren't necessarily binary, not just black and white, zero and one. There are multiple facets, multiple angles. It's interesting to try to look at things from different perspectives.

With AI it's even more glaring. The initial message from an AI is very easy to absorb. The intellectual effort required to systematically question the output at every moment is heavy. When you talk with AI and you know that half the time it's telling you something wrong, it takes a lot of work to keep reminding yourself of that.

How do you spend your free time outside of databases?

I spend some of my free time on IT as well because I enjoy it, and I have plenty of other projects that drive me. The rest of the time is my private life. And that's how it should be.

Do you read tech books?

I'm not even sure I've actually read three tech books in my life. I've never read a tech book from cover to cover. I have some that I browse through.

The two books on my shelf are TCP/IP and Design Patterns. And I think the more interesting one is Design Patterns, by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

Computing is actually very simple. It's zeros and ones. And at the software and developer level, there are just a few development patterns. Not many, and they're enough to do everything you want. At the database level it's almost the same thing: there are patterns for information. The key is knowing which one to use and when.

Are there any projects you'd recommend reimplementing or building on top of PostgreSQL?

Tons. The well-known one right now is Andy Pavlo, one of the professors at Carnegie Mellon.

Unfortunately he's doing it through a Carnegie spin-off. It's really disappointing that it's not open source, because the work he's putting together is extremely promising, specifically around the eBPF layer. There's a kernel-level part to bring into PostgreSQL that could be very interesting. Beautiful things to do there.

Another aspect is that PostgreSQL, despite many improvements, has a major threshold it has never crossed: everything around the WAL and data durability. Pavlo's work makes it possible to have an ACID-native base at the eBPF level. And if you have that, the WAL or the PostgreSQL heap could effectively just be an ACID-native base at the eBPF level, which could give a huge efficiency gain.

The other aspect, which I discussed at length with Simon Riggs, the original founder of 2ndQuadrant, is memory guarantee. We still have terms like checkpoints that date back to when we were talking about magnetic storage. Now we have memory that is guaranteed to still be there when a service crashes. That means we might not need to sync to disk all the time. And maybe there are things to rethink at the low-level layer of the database to gain back efficiency there.

PostgreSQL has no RDMA support, no remote memory support. Every time we do non-procedural things, data gets copied three or four times in server memory and then copied again over the network. One of the likely evolutions is having much more direct access between clients and server memory, and stopping that repeated copying. There's a lot to do.

What are the criteria at Data Bene for hiring the best people?

Clearly, PostgreSQL knowledge is very important. The interest in it, the involvement, the intellectual approach to databases, that matters a lot.

But it's not only that. Let me share the experience of a friend who was recently hired by a large US company. He went through five or seven intense technical interviews. At the end they said "you're hired." He asked: what language do I code in? The guys said we don't care, pick whatever language you want, that's not our problem.

Writing code is no longer a hiring criterion. What matters is the ability to understand why that code was written. Is it relevant? Does this ready-made solution work? Great, it works. But is it the right solution? Not necessarily.

And that's what makes the difference, for us too. We need people who can look at an apparent PostgreSQL expertise recommendation and ask whether it's actually the right call.

Do you have resources to recommend for learning PostgreSQL?

It's worth reading Dimitri Fontaine's book, Mastering PostgreSQL. I co-founded 2ndQuadrant with him, and he developed a huge part of what PostgreSQL extensions are today. It's a very good book for people oriented toward development.

The other resource I find really great is Markus Winand. He's Austrian and has two sites: Modern SQL and Use the Index, Luke. Use the Index is about optimization. Modern SQL is about SQL and it's not PostgreSQL-specific. His courses are excellent. If you want to get into SQL, Modern SQL is probably one of the best entry points.