The Faces of Turso: Meet Mikaël Francoeur

Turso is the next evolution of SQLite. It is a complete rewrite of the iconic database, adapting it to the demands of modern applications. But more important than any specific feature, Turso is an Open Contribution project. We welcome developers to come, contribute and become core members of the community.

We are proud to have a very open community, with individuals coming from a wide variety of backgrounds. Mikaël is no different. It is not that often that one finds a musician turned database engineer, but here we are! And on top of that, he epitomizes what we truly believe an "AI-powered Engineer" should be. Let's learn more about Mikaël!

#Tell us more about yourself

I have a bit of an unusual story. I got a master’s degree in piano performance and a doctorate in musicology. About halfway through my doctorate I realized that software engineering was the field for me: endless learning, standardized collaboration, mental puzzles, all of this resonated deeply with me. When I graduated, I had already programmed some things for my doctorate, but I studied some more and got a Spring certification, which eventually got me my first job.

Five years later, I’m still loving every moment of this career. Currently I’m on a “learncation.” I left my position at Ticketmaster 4 months ago, and started studying and contributing to OSS (mostly Turso) full-time to learn Rust and databases.

#How did you learn about Turso?

Probably like most people, through social media or Hacker News.

#What motivated you to start contributing to Turso?

I already had an interest in Rust and databases when I met you, Glauber, and you told me about the COMPAT.md in Turso. It contains a list of features with their completion state, and if someone sees one they like, they can just implement it.

I wanted to get better at Rust and deepen my understanding of database internals, so I figured that this would be a good way of combining both.

#What are the things you had fun the most doing in Turso?

I think what I’m proudest of would be implementing json_each and json_tree, because I had to learn about SQLite’s virtual tables and internal Jsonb format, deal with non-trivial lifetime issues and self-referential data, implement iterative depth-first search, and dive deep into the quirks of SQLite.

Working on the JavaScript bindings, I also identified an issue in napi-rs, the Rust bindings to Node-API, and got to fix that as well. I had to learn about the parser, runtime code generation, prototype chains, and the TypeScript type definition generator.

Finally, lately I’ve been on a bug hunting spree. I found over 90, ranging from minor incompatibilities with SQLite, all the way to panics and data corruption. I was even awarded the Turso Challenge bug bounty for this last one. All of this has been very rewarding.

#Oh man, and bugs you found! The lore in the street is that you had a bit of help from a friend to do it?

I did, yes. One day, I decided to try something different. I told my friend ChatGPT I was working on a reimplementation of SQLite, and I asked if it could come up with queries that might show bugs in a database that was still in alpha at the time. To my surprise, it generated many useful snippets, and in that day alone I identified over 20 bugs and issues that way.

Since then, I’ve kept using an LLM to generate test cases, and it’s been a surprisingly fruitful endeavour. But of course it’s not all LLMs. I also try really hard to break stuff! And reading the SQLite documentation helps. Sometimes, there’s a paragraph that'll say something like “be careful: this is weird”. These things that are easy to miss.

I think it’s just one of those things that happen when someone has more freedom in their work. If I had an urgent feature to implement that day, I probably wouldn’t have taken the detour and asked an LLM to do some exploratory work, just to see what would happen. I’m happy that it ended up benefiting everyone.

This also says something about testing, and how computers, be they LLMs or fuzzers, are better than humans at identifying interesting test cases. Turso already has a good fuzzing infrastructure, with fault injection and deterministic simulation testing, but fuzzing systems need to be taught where to look for stuff. There’s still room for improvement with Turso’s fuzzers, but I expect they’ll keep evolving as both the community and the project grow.

#How did your contributions to Turso help advance your career ?

One of the reasons I embarked on this “learncation” is that I wouldn’t have been exposed to these things otherwise. When I started contributing to Turso, I already knew some things about database internals, but I was a beginner with Rust. Now I know I can face professional-level challenges in both these domains.

After 4 months of full-time self-improvement, I’m looking for my next professional challenges, in databases internals, distributed computing, or any out-of-the-ordinary challenges. And I now have an interesting open-source portfolio to showcase my abilities.

#Next steps?

If we one day need someone to write the ballad of how Turso came to put databases everywhere, we know just the man for the job! Perhaps his friend ChatGPT will even help with the lyrics?

Want to join Mikaël and our more than 150 contributors in writing the next evolution of SQLite ? Star and join us on Github today!

And since he mentioned he is looking for a job... if you are hiring, drop him a note on LinkedIn!