Inside a YugabyteDB Internship

This retrospective blog from Yugabyte Software Engineer Intern Angela Xu details the projects, people, and lessons she learned during her time on YugabyteDB’s query layer team, including why preventing password reuse is a tricky problem in a distributed database.

I can confidently say this has been the most enriching experience yet, and I’m looking forward to learning more about distributed database systems and contributing to open source.

How it Started

Before joining Yugabyte, I had zero foundation in distributed SQL, but I was drawn in by the fact that YugabyteDB was open source, and working at a core database company seemed like a fun challenge.

I joined the LRT (Languages and Relational Technologies) team, which owns most of the query layer of YSQL, like query planning and processing, and relational features.

Onboarding was smooth, and we were eased into the codebase with simple tickets to start with. Some of the changes I initially worked on included:

1. Improving backend startup logging so parallel/backend worker startup is clearer
2. Adding support for the LOAD statement, which allowed shared libraries to be loaded at session runtime
3. Improvements to the index consistency checker, including adding schema-qualified names to relations, RLS policies, and guardrails

These tasks let me take ownership of my work, starting from just the problem statement. For instance, given our distributed environment, enabling the LOAD statement in YugabyteDB required considering far more edge cases than it would in a single-node system. I had to consider:

1. Who would this impact (superusers)?
2. How would parallel workers access the loaded libraries
3. How would this differ from shared preload libraries?
4. Whether it would conflict with connection pooling in Connection Manager

That research led the team to discover that we needed to make connections “sticky” when the LOAD statement was in use, so an extension wouldn’t end up attached to a backend that was later dropped after a query or transaction completed.

My work on the index consistency checker revealed how RLS policies create discrepancies in the function and across users, depending on whether the system uses multi- or single-snapshot mode. That finding grew into a guardrail for callers subject to RLS, along with early exits when checking large, partitioned tables.

Project: Password Credential Management

I took on this project to meet compliance requirements around secure, profile-level password expiry and reuse prevention. It was highly customer-facing and began with a PRD doc.

To start, let’s look at the current authentication landscape.

Postgres supports multiple authentication methods, including password-based, certificate-based, and external options like LDAP or OAuth. For certificate and external server auth, policies like MFA and credential rotation are standard practice.

Postgres, however, lacks a native policy infrastructure for its internal password auth.

This creates a gap as compliance requirements frequently demand secure, profile-level password management. Our goal was to build on our existing Login Profile schema and add password expiry and reuse blocking to YugabyteDB, giving customers a native place to manage password compliance.

Existing third-party extensions claimed to support password policies, but often stored sensitive data like passwords in unencrypted local files. This is untenable in a distributed system, as this can leave users with inconsistent passwords or unintended login behavior across nodes.

Our solution hooks into role DDL statements natively. It allows us to store password history in a system catalog table, so role data stays globally available and consistently replicated across all nodes.

Following this project, YugabyteDB now supports granular control via ALTER ROLE statements:

ALTER ROLE x SET yb_password_reuse_history TO 3;
ALTER ROLE x SET yb_password_reuse_interval to '365d';
ALTER ROLE x SET password_allow_prehashed TO on;

ALTER ROLE x SET yb_password_validity = '90d';

To prevent password reuse when a user proposes a password change, we intercept the command and check the new password against the history table across two rejection zones:

1. The time-based zone rejects any password that falls within a restricted time window (e.g., a password set in the last 7 days).
2. The count-based zone rejects a password if it matches any of the last N entries in the history table.

If the proposed password hash falls into either zone, we reject the change immediately.

YugabyteDB supports the standard hashing methods: MD5, which uses the role name as a salt, and SCRAM-SHA-256, which uses strong, cryptographically generated salts. We also support pre-hashed passwords for customers using external password managers or OIDC, so plaintext credentials never reach the database.

This approach introduced a subtle problem: a user submitting a pre-hashed string could technically “reset” their password to a different hash of the same underlying password, repeatedly, bypassing our reuse controls.

To address this, we made pre-hashed passwords and reuse policies mutually exclusive. This trade-off preserves support for external integration without compromising the integrity of our validation checks.

I presented an account of this project at a recent Yugabyte Friday Tech Talk alongside the wider Summer 2026 intern cohort. Check out the replay:

Company Culture and Events

I was lucky to join Yugabyte just as the company moved into its new headquarters. The new office has a dedicated lunch area where engineering discussions happen daily. Yugabyte still has the magic of a tight-knit community, where tech conversations surround you, and you can talk to virtually anyone as an equal.

The company is also very AI-forward: Yugabyte CEO Karthik Ranaganathan has commented that curiosity and creativity are our biggest assets.

Yugabyte planned several events during my time as an intern at the company, including game nights and company-wide parties. I also had the pleasure of competing in the poker tournament hosted by another of our interns!

In September 2025, Yugabyte engineers from around the world traveled to our annual offsite to share what they’d been working on. It was awesome to experience Yugabyte at scale and see how quickly the team is building as AI advances.

The talks hit different in person, with a wide mix of people asking questions.

Acknowledgements

This internship wouldn’t have been nearly as enriching without my mentor, Karthik Ramanathan, who always encouraged me to keep asking questions and held work to a meticulous standard.

Special shoutout to Mihnea for organizing the YugabyteDB Friday Tech Talk (and for my interest in buffer flush cases), Jason for being the reviewer around, Vicky Harp for being the best PM, my fellow interns Samson, Vivian, and William for being great company to check back concepts with, and everyone else at the office who made every day worth it.

If I could give any advice to anyone looking to get into this space: read Designing Data-Intensive Applications, stay curious, and contribute to open source!

Want to get involved?

• Check out open roles at Yugabyte
• Join the community
• Start building with open source YugabyteDB