DataHub at Coinbase

DataHub is the internal tool Coinbase uses to manage its data. The data engineers on my team build what runs inside it: the data catalog, classification, lineage, data quality, profiling, governance, ETL and pipelines, retention and deletion, compliance, and the databases underneath all of it.

I lead the frontend for the whole app and own its infrastructure. The job is two things: developer experience, so the data engineers can easily build their own apps inside it, and user experience, so what they build is good to use. I have also written skills and rules for those practices, so the team can follow them on their own.

Rebuilding the frontend

The frontend used to sit inside a large Python monolith. Every UI change rebuilt the whole thing, so shipping a small fix was slow for everyone.

I moved it out into its own repo, on the frontend setup the rest of the company already uses. I wrote the proposal and the technical design first and got every engineer on the team to agree on it before any code moved.

Then I built tooling so each team could migrate its own app. A few teams did. Rather than let the rest stall, I migrated the remaining apps myself using the same tooling.

I set up the production infrastructure for the new site too. That part was new to me. It meant a BFF (Backend for Frontend) pattern, a small server that sits in front of the old backend and handles single sign-on across the two domains, plus the deploy pipeline and DNS.

Old and new ran side by side the whole time, one app moving over at a time, so nothing went down. The final switch was one change that could be undone.

What else I have built there

DataStores. One place to manage Postgres, MongoDB, and ElastiCache, instead of many separate AWS consoles and access tickets. You can search every database, see how it is laid out, run queries with role-based access and an approval step, edit parameter groups, run engine upgrades, read performance insights, and see right-sizing suggestions with what they would save. There was no designer on it, so I did the design in Figma along with the build. It started as an idea I took to my manager, and the datastores team works on it with me now.

Surveys. I added Sprig so we could ask people for feedback inside the tools they were already using. I designed the user identification so it never exposes personal data, and caught a bug before release that would have shown people the same survey over and over.

AG Grid Enterprise. The data team needed a UI that could handle very large amounts of data. I proposed AG Grid, and we started on the free version. The team liked it enough that we moved to the paid Enterprise subscription, for the things the free version does not do: grouping rows, pivoting and aggregating, selecting ranges of cells, and exporting to Excel.

Then I did the rest of it. Requirements and quotes with the vendor, onboarding them as a new supplier, security review, and the licensing. Licensing was the slow part. Their model was confusing and badly documented, so it took a lot of back and forth between us and them before both sides agreed on which licenses we needed and how many.

The upgrade was a breaking major version and it touched nearly every table in the app. I automated most of it with their codemods and with Cursor, feeding it the breaking-change notes. Every table in DataHub runs on it now, and I still own anything AG Grid, including the renewals.

Impact

A frontend change now builds and deploys on its own, instead of rebuilding the monolith.

The codebase is fully typed, back on a supported runtime, and on the current design system after sitting two major versions behind.

Each app is owned by the team that built it, rather than everything sharing one routing file.