About

I’m Vignesh Kumar A, a database engineer in Chennai. I work on the internals of a horizontally scalable distributed PostgreSQL: data spread across many nodes, queries planned and executed across them, and transactions that touch more than one node and still commit or abort together. Before that I spent four years on the server side of a point-of-sale platform in Java, where the failures I could not explain are what pulled me down into storage and transactions.

What I work on

One engine, in the order a change moves through it.

A row lives on a fixed-size page inside a file; an index entry lives on a page of a tree. Before either page changes on disk, the engine writes a short note describing the change into a journal and makes that note durable first (the write-ahead log). Crash recovery is reading the journal back.

Nothing is overwritten in place. An update writes a new version of the row and leaves the old one alone, so two sessions can read the same row and correctly see different things. Which version you see depends on when your statement started: MVCC, and the tuple visibility rules that decide it.

When a transaction touches data on two nodes, neither node can decide the outcome alone. Both write down that they are ready, then a coordinator tells them the answer (two-phase commit). The hard part is when the coordinator dies between the two steps. Recovery then has to find the transactions left in doubt and finish them.

A query does not need to visit every node. The planner works out which shards could possibly hold matching rows and skips the rest (shard pruning), then splits the work across the nodes that are left, pushes down whatever they can compute themselves, and combines what comes back.

Shards also move while the system is serving: ranges get extended, retired, rebalanced. Each of those is a change to live metadata, so it has to be checked before it runs, safe to restart if it fails halfway, and possible to rehearse without touching a shard.

Most of this is C, and most of it is debugged in LLDB across a multi-node cluster.

What I have built

At the level I can talk about publicly: what each thing does, not how the product does it. The numbers are the ones on my resume.

• A read-only consistency verifier for the cluster. Fifty checks that read the cluster and report what disagrees: shard placement, colocation, residue left behind by a replication that half-finished, two-phase-commit state, node health. It fans out to every node over libpq asynchronously with a deadline per node, so one unresponsive node cannot hang the run, and it fingerprints every finding with a SHA-256 hash so the same defect keeps the same identity across scheduled runs. About 15,000 lines of C and SQL, modelled on PostgreSQL’s amcheck, running against a ten-node cluster.
• A logical-decoding output plugin that turns the write-ahead log into JSON. The log already describes every change the server made; this reads it and emits one JSON record per INSERT, UPDATE, DELETE and TRUNCATE, honouring the row filters and column lists a publication declares. A background worker beside it publishes throughput and operation-mix counters per replication slot, kept across restarts.
• The operation layer for range-partitioned shards. I rewrote it, folding more than 2,800 lines of user-defined function code into one operation model with cutoff expressions and scheduling that knows which kind of operation it is running. Every range operation now has a dry run, so an operator sees what it would do to live cluster metadata before a single shard is mutated.
• Before that, the sync platform for a point-of-sale product, in Java. One event per change over Kafka instead of M×N API calls, which cut upstream API load by 99% and let the platform ride out an outage in the finance platform it syncs with. A transactional outbox written in the same MySQL transaction as the sale, with background retry, for 99.9% consistency at more than a thousand transactions a minute. A cache split into three isolated segments with version-based invalidation: hit rate from 84.3% to 98.1%. A three-level circuit breaker. Correlation-ID tracing across asynchronous callback threads.

Background

B.Sc. Computer Science in Chennai, 2019 to 2022. I joined Zoho in July 2022 as an incubation trainee and stayed.

From August 2022 to June 2026 I worked on a distributed point-of-sale platform: mostly the sync layer that keeps registers consistent with a finance platform while they spend part of their day offline. Most of the hard problems there had the same root. A sale committed and the event announcing it lost, because the two writes were not in one transaction. A cache that answered quickly and wrongly. Two registers that disagreed about what happened, with no rule for who wins. Replaying a day of events and getting a different total. Every one of those is a question about durability, isolation and ordering, and the answers all lived a layer below the code I was writing: in how a database writes, what it makes visible, and when it is allowed to say a write is safe.

So I started reading PostgreSQL’s source to find the answers. In June 2026 I moved to the distributed database team at ZLabs, and now I work on those problems every day.

How I work and learn

I write the explanation I wish I had found: the one-sentence idea, then why the problem exists, then the mechanism with a plain word before the real term, then a worked example and the gotchas. When something is new to me I have an AI explain it as if I were about to explain it to someone else, which is a quick way to find the step I have been skipping. The test is the same either way: if I cannot write it plainly, I do not understand it yet, and it stays in notes until I can.

Talk to me about

PostgreSQL internals: the write-ahead log, MVCC, the planner, the C extension surface. Distributed transactions and what recovery has to clean up after them. Storage engine trade-offs: B-tree against LSM-tree, and when separating the values from the keys earns its cost. Offline-first sync and the conflicts it creates. Moving from product work into database internals, and how that actually happens.

Elsewhere

GitHub · LinkedIn · vignesh@sudohulk.com

The type, the design rules and the licence are on the colophon.