Database development has changed quite a lot since then. When I first started working on databases in the 1990s, two things were true that made it much easier for relatively inexperienced developers (like myself at the time) to produce a reasonably good result. First, the state-of-the-art implementations at the time were incredibly well-documented in an accessible way and the academic literature also reflected those designs. Second, the implementations were relatively simple and straightforward; you did not need esoteric systems knowledge and design theory to write code that was competitive with other implementations. The most complicated thing you had to worry about was lock structures and concurrency control. Not only were there relatively simple examples to copy and study, the gap between those examples and the state-of-the-art was pretty small.

Neither of these is true today. The design of state-of-the-art implementations are often poorly documented; the computer science has evolved radically since the 1990s with significant gaps in the literature; competitive implementations require real expertise in silicon architecture and Linux kernel internals, you can't just write something obvious in C and expect a good result. And that's without even getting into difficult topics like distributed execution, parallel orchestration, scheduler design, etc that we didn't have to worry about back then.

I'm not sure I'd be able to bootstrap the necessary expertise to build database engines today like I did back then.