Building data systems end-to-end — normalized schemas, automated ingestion pipelines, slow-query diagnosis, and index tuning. 6 chained projects. One connected dataset. Real results.
MySQL · Apache Airflow · MinIO · Python · Docker
swe-2.tail174d56.ts.net
Each project feeds the next. Chained output, one connected dataset.
The complete technical record, in the order it actually happened: GTID-based replication from scratch, a first failover attempt that surfaced real gaps and was deliberately paused, then a completed drill and a genuine multi-app production incident. Every command below actually ran.
Built and verified a real Debezium/Kafka Connect CDC pipeline streaming project1_jobs from self-hosted MySQL to self-hosted Postgres, zero lag, row counts matched. This is the CDC piece only — the other 9 app databases, the actual cutover, and any cloud target are deliberately not done yet.
Read Full Case Study →Add role-based access control, PII column masking, and audit logging to an existing schema — and specifically, instrument the `portfolio_admin` write-path built earlier this session (2026-08-18) with real audit logging, so the project is partly about auditing this portfolio's own system rather than only a synthetic exercise.
Read Full Case Study →Turn Project 3's manual `mysqldump --single-transaction | gzip` runbook into a scheduled, automated pipeline with retention policy and — critically — automated, *tested* restores, not just backups that are assumed to work.
Read Full Case Study →This is the detailed technical record in the same style as the replication project's writeup: every command and query actually run, every issue actually hit, and how each was actually resolved — including a real cascading connection-exhaustion incident during the final verification step, kept in full because it's stronger evidence than a clean scripted test would have been.
Read Full Case Study →Load the schema with a million synthetic rows and run a full slow-query diagnosis and tuning case study.
Why I run my own MySQL instead of a managed one, the Docker/Tailscale stack behind it, and how this blog itself works under the hood.
Open to data analyst, database engineer, and data engineering roles. I prefer async-first communication — GitHub issues, email, or LinkedIn DMs.
Send Email →