Meet the Writer: Nan Ei Ei Kyaw on Choosing the Right Vector DB

Welcome to HackerNoon's Meet the Writer Interview series, where we learn a bit more about the contributors that have written some of our favorite stories. Today, we're speaking with Nan Ei Ei Kyaw, an engineer whose career path from embedded systems to AI reflects the broader industry shift toward intelligent systems.

From Hardware Validation to AI Systems

Nan Ei Ei's technical foundation was built in the demanding world of embedded software engineering. For over a decade, she worked on cross-platform test applications using Qt QML and C++ to validate hardware components in real-time operating systems. This experience gave her a deep appreciation for systems where timing, reliability, and direct hardware interaction are non-negotiable.

Later, she applied these principles to autonomous robots, developing intuitive interfaces that bridged complex mechanical systems with human operators. The transition from embedded systems to data analysis in the financial loans domain wasn't a departure from her core interests, but rather an expansion into where data meets real-world decision-making.

"I enjoy working at the point where systems, data, and real-world decision-making meet," she explains. This perspective—shaped by years of building systems that must work in the physical world—directly informs her approach to AI engineering.

The Vector Database Decision

Her latest top story, "How to Choose the Right Vector Database for a Production-Ready RAG Chatbot," emerged from a practical need. When evaluating vector databases for her own use case, she found herself spending significant time comparing options. The experience motivated her to write an article that could help others make faster, clearer decisions.

The article focuses on four critical dimensions: setup time, infrastructure requirements, learning curve for developers, and minimizing DevOps effort. These aren't abstract considerations—they're the practical hurdles that determine whether a project succeeds or gets stuck in implementation hell.

"When I was evaluating vector databases for my own use case, I spent a significant amount of time comparing options," she notes. "That experience motivated me to write this article so others could benefit from a clearer, faster decision-making process."

Writing as Engineering Discipline

Nan Ei Ei's writing routine reflects her engineering background. She starts by reflecting on case studies and problems she's solved, then outlines the most straightforward way to explain them. The structure comes first, then the connection of dots, followed by the actual writing.

"I usually write my articles in the morning or late at night when my mind is clear, and the environment is quiet," she says. This disciplined approach mirrors the focused attention required for embedded systems programming or complex algorithm development.

The biggest challenge in her writing process is shifting from implementation to explanation. "As engineers, we often dive straight into building components, but writing requires slowing down, zooming out, and articulating the why behind every decision," she explains.

A manager's advice became her guideline: write in a way that even readers unfamiliar with the topic should understand at a very high level. This principle—clarity over complexity—shapes her technical writing.

Bridging the AI Divide

Looking forward, Nan Ei Ei wants to deepen her work in AI systems, focusing on reliable and accessible solutions. Her long-term goal is to help bridge the global AI divide by empowering developers in underserved regions with modern tools and knowledge.

This ambition connects directly to her writing philosophy. By sharing practical insights from her day-to-day work, she aims to make complex technical concepts accessible to a broader audience. Her follow-up article, about feeding RAG data into LLMs with a focus on hybrid approaches for chatbots, continues this mission.

The HackerNoon Community

For Nan Ei Ei, HackerNoon represents something rare in technical publishing: a platform where writers can be honest and creative. "It gives us space to share the deep dives, strong opinions, and not the surface-level content," she says.

This aligns with her own writing approach—substance over style, practical insights over theoretical discussions. The platform's emphasis on builders sharing what they've learned creates a feedback loop where real-world experience informs the broader community.

Practical Takeaways for Developers

Nan Ei Ei's journey offers several insights for technical writers and engineers:

1. Start with real problems: Her vector database article emerged from personal evaluation challenges, not abstract research.
2. Structure before writing: Clear outlines prevent meandering explanations.
3. Explain the why: Technical decisions need context, not just implementation details.
4. Bridge experience gaps: Write for readers who haven't spent years in your specific domain.

Her approach demonstrates that effective technical writing isn't about simplifying complex topics, but about making them accessible without losing depth. It's a skill that becomes more valuable as technologies like vector databases and RAG systems become increasingly central to AI development.

For developers facing similar decisions, her article provides a framework that goes beyond feature lists to address the practical realities of production deployment. The focus on setup time, infrastructure, learning curve, and DevOps effort reflects the priorities of someone who has actually built and maintained these systems.

As AI continues to evolve, voices like Nan Ei Ei's—grounded in practical experience and committed to clear communication—become increasingly valuable. They help bridge the gap between cutting-edge research and production-ready implementation, making advanced technologies accessible to more developers.

Her work reminds us that the most useful technical writing often comes from engineers who have wrestled with the same problems their readers face, and who have found solutions worth sharing.

---

Learn more about choosing vector databases in Nan Ei Ei's full article: How to Choose the Right Vector Database for a Production-Ready RAG Chatbot