Hacker Newsnew | past | comments | ask | show | jobs | submit | viveknathani_'s commentslogin

Location: Bangalore

Remote: Yes

Willing to relocate: Maybe, for the right opportunity Technologies: Rust, Go, C++, PostgreSQL, Redis, Linux, TypeScript

Resume: https://vivekn.dev/resume.pdf

Email: work@vivekn.dev

Software engineer with 3+ years of experience across startups, increasingly working on databases, systems, and infrastructure.

I previously cofounded Mars Computers, where I built a low-latency remote desktop system with a custom video streaming pipeline in Rust and worked across networking, OS primitives, and bare-metal infrastructure. I've also built production backend systems involving real-time financial data, PostgreSQL, Redis, WebSockets, and async processing.

More recently, I've been working on database internals and systems: contributing to SlateDB (a Rust LSM-tree storage engine), experimenting with PostgreSQL/Linux I/O and tail latency, and building database tooling.

Looking for hard engineering problems around databases, infrastructure, networking, distributed systems, or systems-heavy backend work. I like going down rabbit holes, understanding why things behave the way they do, and owning things end-to-end.

For more info: https://vivekn.dev


extremely creative stuff!


great reading list, but also a great career arc OP! loved skimming through your site!


Thank you :)


adoption of pgrx, durable execution becoming popular - good things! but not a fan of keeping complex flows inside the DB


interesting approach, was exploring a Postgres to Clickhouse CDC setup while helping a team sometime back, this seems better as it allows separating the compute (query server) and storage (s3) layers, and thereby allowing us to be creative in cost reductions


Aside from the cost, my major motivation is to keep the infrastructure simple. The data is already there in Postgres, so I didn't want to add another data warehouse. I have also shared my thoughts on where this is heading https://viggy28.dev/article/postgres-gateway-drug/


It depends on the use case. For real-time, customer-facing analytics, ClickHouse’s MergeTree engine is a natural fit, so a Postgres → ClickHouse CDC setup with low latencies (single-digit seconds) is better.

Replication to Iceberg/S3 is better suited for offline analytics and data warehousing use cases. You can use the same ClickHouse engine to query layer Iceberg data in S3.


makes sense!


huge +1, i also just hate reading large HTML reports that AI spits out.


Wrote something about applying math in modelling a rate-limiting scenario for API clients. Felt like posting it here. Happy to hear your thoughts, HN!


hi! thanks for explaining this bit in detail. i agree, fragmentation should be handled in the transport layer!


lol!


hi, thanks! like somebody else mentioned, it is the term used in the linux kernel itself. although i do see your point - NAT does help in reducing the attack surface.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: