profile

Analytics engineer — Atlanta, GA

Prudhvi Vuppalapati

I build the warehouse layer other teams query.

Four years of backend work on Postgres, MySQL, RDS and DynamoDB: tuning queries, sizing caches, and keeping the dashboards that told us when they broke. What I build now sits on the other side of that boundary. The pipelines that turn those operational databases into something a team can actually ask questions of.

My paid work so far has been backend engineering. The data-platform work is the five repositories below, and it is the job I am moving toward.

Each one runs end to end across ingest, model and serve. Each boots from a clean clone against synthetic data, with no warehouse account or credentials required, and each is tested at the layer where it would actually fail.

Read the pipeline Email me

pipeline

Ingest, model, serve

Five repositories, arranged the way a warehouse is: raw change comes in on the left, tested models sit in the middle, and the things people query come out on the right.

  • Ingest 1 repo Raw change, captured as it happened.
  • Model 2 repos Cleaned, joined, and tested before anything downstream reads it.
  • Serve 2 repos The tables and measures people actually query.

  1. ingest

    most complete

    StreamGuardchange data capture

    Postgres write-ahead log to ClickHouse in seconds, not hours.

    Reads Postgres logical replication through a Debezium connector, streams every committed row change onto Kafka topics, and lands them in ClickHouse. It handles the three things that actually break CDC pipelines in practice: duplicate events, schema evolution, and windowed aggregation. Parse and sink failures go to a dead-letter topic rather than being dropped, and consumer lag and throughput are provisioned onto a Grafana dashboard.

    Ships with a documented failure-injection guide, so the recovery paths are demonstrable rather than asserted.

    StreamGuard change-data-capture pipeline Postgres emits row changes on its write-ahead log. A Debezium connector turns them into events on three Kafka topics. A stream processor deduplicates by log sequence number, reconciles schema changes and computes tumbling windows, then writes to ClickHouse. Parse and sink failures are routed to a dead-letter topic instead of being dropped, and consumer lag and throughput are reported to Grafana. Postgres orders, customers Debezium reads the WAL Kafka 3 topics processor dedupe · window ClickHouse raw + rollups dead-letter topic schema drift reconciled in-flight consumer lag + throughput on Grafana
    • Postgres
    • Debezium
    • Kafka
    • ClickHouse
    • Prometheus
    • Grafana
    • Docker

    streamguard-cdc — open StreamGuard on GitHub

  2. model

    Lakehouse Quality Gateenforcement, not reporting

    Data quality that stops the pipeline instead of filing a report.

    Most lakehouse data quality is passive: tests run, a report goes red, and nobody notices until the numbers look wrong days later. Here a Great Expectations checkpoint sits physically between the dbt staging layer and the marts on an Apache Iceberg lakehouse. When expectations fail the Airflow DAG stops, so no mart is ever built on top of bad data, and a structured alert naming the exact failing expectations and a sample of offending row IDs goes out over a webhook.

    A chaos module injects the failures on demand, so the gate is proven to hold rather than assumed to.

    Lakehouse quality gate Raw data lands in Apache Iceberg tables and is shaped by dbt staging models. A Great Expectations checkpoint sits between staging and the marts: when expectations pass, the marts are built; when they fail, the Airflow DAG halts so no mart is ever built on bad data, and an alert naming the failing expectations and sample row IDs is sent to a webhook. Iceberg raw tables dbt staging cleaned, joined checkpoint Great Expectations marts built DAG halts · webhook alert no mart is ever built on bad data
    • Airflow
    • dbt
    • Apache Iceberg
    • Great Expectations
    • Python
    • Docker

    lakehouse-quality-gate — open Lakehouse Quality Gate on GitHub

  3. model

    Field Ops Cost Auditcost-to-serve modelling

    True cost per job, and where SLA breaches actually concentrate.

    Field-service operators need two answers they usually can't get, because dispatch, routes, timesheets, fuel and tickets live in disconnected tables in inconsistent shapes. This reconciles them through a tested dbt pipeline: staging views, a business-logic layer, then reporting views. The hard SQL is written once and covered by tests, including recursive route sequencing, utilization windows and cost allocation.

    Runs fully offline on DuckDB against a generated dataset. No warehouse, no credentials, reproducible from a clean clone.

    Field operations cost-to-serve model Four disconnected operational tables — dispatch, routes, timesheets and fuel — are shaped by dbt staging views, then joined in a business-logic layer that does the recursive route sequencing, utilization windows and cost allocation once. The result is two tested reporting views: cost-to-serve per job and SLA breach concentration. The whole pipeline runs offline on DuckDB. dispatch routes timesheets fuel dbt staging a view per source business logic recursive route sequencing utilization · cost allocation cost-to-serve per job SLA breach concentration every view under dbt tests · DuckDB, no warehouse
    • dbt
    • DuckDB
    • SQL
    • Python
    • pytest
    • GitHub Actions

    field-ops-sql-cost-audit — open Field Ops Cost Audit on GitHub

  4. serve

    Retail Margin Cockpitgoverned star schema

    One governed margin number, replacing five spreadsheets.

    At small retail and DTC companies, "what's our margin?" is a multi-hour exercise across POS, Shopify and a hand-maintained inventory sheet that never joins cleanly, so finance and ops quote different numbers. This turns those raw exports into a tested dbt star schema, with not_null, unique, relationships and accepted_values tests on every key column, then adds the DAX measure library and row-level-security design that let a regional manager open Power BI and see only their own region.

    A seeded generator produces two years of internally consistent retail history. Same seed, same bytes, every run, which is what makes everything downstream testable.

    Retail margin star schema and row-level security POS, Shopify and inventory exports are seeded through dbt into a star schema: a central sales fact table joined to product, channel, date and region dimensions, with not-null, unique, relationships and accepted-values tests on every key column. A DAX measure library and row-level security design then expose it in Power BI so a regional manager sees only their own region. POS Shopify inventory dim_product dim_date chan region fact_sales DAX row-level security · a manager sees only their region tests on every key column
    • dbt
    • SQL
    • Power BI
    • DAX
    • Python

    retail-margin-cockpit — open Retail Margin Cockpit on GitHub

  5. serve

    cohortkitretention analytics library

    Cohort triangles and RFM for any customer/order/revenue table.

    Every subscription and e-commerce business needs the same three retention views: a cohort-retention triangle, an RFM segmentation, and revenue by acquisition cohort. They usually live in a BI tool or a pile of copy-pasted SQL. This turns them into three tidy-DataFrame calls and a CLI, running in-process on DuckDB, so they work in a notebook, a test, or a cron job with no infrastructure at all.

    24 tests, no network, no configuration.

    cohortkit retention outputs Any table with customer id, order date and revenue columns is read in-process by DuckDB and returned as three tidy DataFrames: a cohort retention triangle where each acquisition month decays across later months, an RFM segmentation, and revenue by cohort. No warehouse, no network and no configuration are involved. any table customer · date · revenue DuckDB in-process RFM segments revenue by cohort retention triangle month 0 → month 6
    • Python
    • DuckDB
    • pandas
    • uv

    cohortkit — open cohortkit on GitHub

record

4 yrs 3 mos of engineering

Backend and platform work on the operational systems that the pipelines above are built to read.

  1. Nov 2024 — Present

    1 yr 9 mo

    Full Stack Developer

    CGI · USA

    • Cut average API response latency by ~25% with Redis caching and query optimization across Spring Boot REST services.
    • Built and ran a Spring Boot microservices estate with Netflix Eureka service discovery and Spring Cloud Config.
    • Deployed backend infrastructure on AWS Lambda, App Runner and S3.
    • Validated API contracts, performance and security with Postman and Swagger ahead of each release.
    • Java
    • Spring Boot
    • Redis
    • React
    • AWS Lambda
    • S3

  2. Jan 2021 — Jul 2023

    2 yr 6 mo

    Junior Full Stack Developer

    Lumen Technologies · India

    • Tuned data access with Spring Data JPA over MySQL and PostgreSQL, and integrated Amazon RDS and DynamoDB for high-volume transaction workloads.
    • Instrumented services with Spring Boot Actuator, Prometheus and Grafana dashboards, cutting mean time to resolution by ~40%.
    • Added AWS CloudWatch logging and monitoring, reducing incident response time by ~35%.
    • Migrated monolithic applications to Spring Boot microservices, cutting deployment time by ~30%.
    • Java
    • Spring Data JPA
    • PostgreSQL
    • MySQL
    • DynamoDB
    • Prometheus
    • Grafana

Education

  • May 2025

    Master of Science

    Kennesaw State University · Georgia, USA

stack

Tools

Marked skills are used by a repository listed above.

Pipelines & orchestration

  • dbt (used by a repository above)
  • Airflow (used by a repository above)
  • Debezium (used by a repository above)
  • Kafka (used by a repository above)
  • Great Expectations (used by a repository above)
  • Docker (used by a repository above)
  • Prometheus (used by a repository above)
  • Grafana (used by a repository above)
  • GitHub Actions (used by a repository above)
  • Kubernetes
  • Jenkins
  • Maven
  • Gradle

Warehouses & stores

  • PostgreSQL (used by a repository above)
  • ClickHouse (used by a repository above)
  • DuckDB (used by a repository above)
  • Apache Iceberg (used by a repository above)
  • MySQL
  • SQL Server
  • MongoDB
  • DynamoDB
  • Amazon RDS
  • Redis

Languages

  • SQL (used by a repository above)
  • Python (used by a repository above)
  • Java
  • JavaScript

Modelling & analysis

  • Star schema (used by a repository above)
  • pandas (used by a repository above)
  • pytest (used by a repository above)
  • Power BI (used by a repository above)
  • DAX (used by a repository above)

AWS

  • S3
  • Lambda
  • EC2
  • RDS
  • DynamoDB
  • IAM
  • Elastic Beanstalk
  • CloudWatch
  • Route 53

Backend

From four years of Java service work — the operational systems these pipelines read from.

  • Spring Boot
  • Spring Data JPA
  • Spring Cloud
  • Spring Security
  • REST APIs
  • Microservices
  • Hibernate
  • JUnit
  • Mockito
  • Postman
  • Swagger
  • React
  • Angular

contact

Get in touch

Open to analytics and data engineering roles. The fastest way to reach me is email.

jaswanthjeswa85@gmail.com

Or find the code on GitHub, or take the one-page résumé (PDF).