Hello, I’m Basant Bhattarai.

Senior Data & AI Engineer

I design data platforms, and the agentic systems that run on them.

Nine years on systems that have to keep working: terabyte-scale ingestion, the databases underneath, and agents that write into governed stores, not a chat window.

Basant Bhattarai
Taking one or two consulting engagements
  • 9 years in software engineering
  • 15 TB+ production data footprint
  • 100M+ events processed daily

Three problems worth calling me about.

How an engagement works
  1. Data platforms that outgrew their first architecture

    Ingestion, processing and serving that worked at one scale and stopped working at the next — plus the cost model underneath, which is usually the real reason the conversation started.

    Evidence Rebuilding a production data platform

  2. Agents that have to touch production data

    Not a chat demo. Typed output, provenance, evaluation and a review path, so a model result is only allowed to become state when it can be justified — and there is a defined answer for when it cannot.

    Evidence Turning model output into auditable product state

  3. Databases that have to survive failure

    High availability, backup, restore and upgrades, handed over with a runbook your team owns after I leave — and numbers taken from a rig you can rebuild rather than from a vendor page.

    Evidence Orchestrated failover and a restore I performed

Five systems, and the decisions that kept them running.

View all work

01Professional practice2020 – present

Rebuilding a production data platform for scale and recovery

Data Engineer → Senior Data Engineer

A six-year platform story: faster processing, lower cost, safer change, and recovery designed before the incident.

50% faster core processingbefore/after wall-clock runtime of the rebuilt core pipeline · 2020–2024 Data Engineer role

40% lower infrastructure costbefore/after infrastructure run-rate across the Kubernetes migration · 2020–2024 Data Engineer role

Python · SQL · Apache Spark · Apache Kafka · Apache Airflow · dbt

  • Data quality & contracts
  • Observability & SLOs
  • Iceberg & the lakehouse

02Professional practice2024 – present

Turning model output into product state you can audit

Senior Data Engineer

A governed analytics workflow with typed state, provenance, evaluation, review, and an honest fallback path.

60% faster analytics deliverybefore/after delivery time for recurring analytics requests · 2024–2026 Senior Data Engineer role

75% less analyst manual effortbefore/after manual effort per recurring analyst request · 2024–2026 Senior Data Engineer role

Python · Pydantic · LangGraph · LangChain · CrewAI · Google-ADK

  • AI agents in production
  • Data quality & contracts
  • RAG

03Independent product2024 – present

ClickHomes: an independent real-estate product

Founder and sole engineer — built outside my day job

A real-estate product I own end to end: PostgreSQL for truth, ClickHouse for speed, RESO as the only way in

90+ SQL migrationsversioned migration files in the repository

Python · FastAPI · PostgreSQL · ClickHouse · RESO · Next.js

  • PostgreSQL
  • Data quality & contracts
  • AI agents in production

04Measured lab2026

Multi-engine HA lab: eight failover scenarios

Personal lab

Six database engines, eight failover scenarios, one laptop — with the numbers

8 of 8 failover scenarios passedmy own test plan, executed on Docker with 8 CPU / 12.5 GB · 2026

383 µs replay lag measured on one hosta single pg_stat_replication reading with primary and hot standby on the same machine — loopback, no network, so it is a floor for the configuration rather than a latency anyone should expect across hosts

MongoDB · ScyllaDB · SolrCloud · MariaDB · Galera · Redis

  • Distributed databases
  • PostgreSQL
  • Observability & SLOs

05Measured lab2026

Orchestrated failover and a restore I actually performed

Personal lab

A production-shaped Postgres cluster on one laptop: killed the primary, rebuilt the replica, recovered a dropped table

10–20 s observed promotion window after SIGKILLSIGKILL of the Patroni leader, then patronictl polled every 10 s until the survivor showed as Leader — so 10 s is the measurement resolution, not the precision of the result · 2026

under 5 s replica rebuilt from backuppatronictl reinit, timed from the pgBackRest restore command begin to Patroni reporting the replica created · 2026

PostgreSQL · Patroni · etcd · pgBackRest · Ansible · Rocky Linux

  • PostgreSQL
  • Distributed databases
  • Self-hosted ops

06Measured lab2024 – 2026

A lakehouse, and the RAG pipeline that runs on it

Personal lab

The two halves of the thesis as one system: Trino and Iceberg underneath, retrieval and answers on top, both measured

88 ms one-month predicate over 1.5M Iceberg rowsmedian of 7 server-side runs from system.runtime.queries, after 2 warm-ups, on a month-partitioned Iceberg table · 2026

909,968 rows recovered by snapshot rollbackunqualified DELETE, then ALTER TABLE EXECUTE rollback_to_snapshot, counted against the pre-incident total · 2026

Trino · Apache Iceberg · Apache Polaris · StarRocks · Apache Spark · Delta Lake

  • Iceberg & the lakehouse
  • RAG
  • Distributed databases

What I learned, written clearly.

Browse writing
  1. Tutorial Measured on my own hardware

    A lakehouse spine: Trino, Iceberg and Polaris, with credentials that expire

    Build Trino 483 on Iceberg with Apache Polaris as the REST catalog, then prove the vended S3 credentials cannot read the table next door.

  2. Tutorial

    A RAG pipeline on a Delta lakehouse, and the bug that survived being fixed

    Scrape to bronze, silver, gold on Spark 4 and Delta, embed into Chroma, and serve answers that cite their sources or decline to answer.

  3. Tutorial Follow-along runbook

    Patroni HA on PostgreSQL 18 with etcd, proven by killing the primary

    Build a two-node Patroni cluster on Rocky 8 under QEMU, then SIGKILL the leader and measure the promotion, the timeline bump, and the pg_rewind rejoin.

Based in Kathmandu. Working across European afternoons and US mornings.