1) Let’s start with you!

Tell us a bit about yourself – your background, current role, and what excites you most in the world of tech.

I’m a Database Administrator with about 10 years of experience in Oracle and 2 years working with PostgreSQL on AWS RDS. My journey has always been rooted in production — keeping databases reliable, safe, and performant under real-world pressure. What excites me most right now is the intersection of database engineering and SRE culture: building proactive, observable, automated systems rather than just reacting to incidents. I’m actively transitioning toward a Database SRE role focused on PostgreSQL, and that pursuit is pushing me to grow across cloud, tooling, and open-source — which honestly feels like the most energising phase of my career so far.

2) Why PostgreSQL? What inspired you to explore or switch to PostgreSQL?

My first exposure to PostgreSQL came through work, when my team started adopting it on EDB PostgreSQL alongside our Oracle stack. What pulled me deeper was how open, extensible, and community-driven it is — a stark contrast to the closed ecosystem I was used to. The more I worked with it, the more I appreciated how much power it puts in the hands of the DBA. And frankly, a production incident involving Foreign Data Wrappers that nearly cascaded to live tables made me realise I needed to understand PostgreSQL not just as a user, but deeply — and that curiosity never left.

3) What are you working on with PostgreSQL right now?

Share the cool stuff you’re building, learning, or solving using PostgreSQL.

I recently built and open-sourced pg-snap-anon (github.com/sskhedekar/pg-snap-anon) — a CLI tool that anonymizes AWS RDS PostgreSQL snapshots without ever connecting to the production database. It was born directly from a P1 incident I lived through, where an FDW connection from a snapshot environment accidentally propagated writes to live production tables. The tool addresses a real gap in the RDS ecosystem around safe, production-isolated data masking. Beyond that, I’m preparing for the EDB Advanced PostgreSQL Essentials v16 certification and exploring AI-assisted DBA tooling — specifically MCP servers for PostgreSQL — as part of my DBSRE transition journey.

4) What’s been your biggest learning or challenge on this journey?

A lesson, mistake, or an aha moment, we’d love to hear about it!

The biggest lessons have all come from real production problems, not textbooks. A P1 incident involving FDW connections propagating changes from a non-production environment to live tables taught me that “isolated” doesn’t always mean safe — and that the best guardrails are ones that make the unsafe path structurally impossible. That directly inspired pg-snap-anon. A separate frustration with fragile EC2-based solutions for query management pushed me to build pg_query_guardian — a self-contained PL/pgSQL watchdog that auto-terminates runaway SELECT queries on RDS read replicas, with zero external dependencies. The recurring aha moment across both: you don’t need to wait for the “right” infrastructure or tools to exist. PostgreSQL itself is often powerful enough — if you understand it deeply enough to use it.

5) Your wisdom to rookies like yourself?

Don’t wait until you fully understand something to start using it — production will teach you faster than any course. But also don’t learn only from production! Build things alongside your day job, even small tools, even if nobody uses them. The act of building forces you to confront gaps in your understanding that reading never will. And join communities like Postgres Women India early — the collective knowledge and generosity in the PostgreSQL community is genuinely unlike anything I’ve experienced in tech.

6) Finally, describe your PostgreSQL journey in one word.

Yep, just one!

Transformative

7) Who or what has influenced your PostgreSQL learning the most?

A mentor, a community, a course, a project, tell us what or who helped you grow.

A few things stand out. The Postgres Women India live course was genuinely my entry point into structured PostgreSQL learning — it gave me a foundation I could build on with confidence. Beyond that, real production incidents have been my most unforgiving but effective teachers. The open-source community has also been a huge influence — reading how others architect solutions, debug issues, and share knowledge publicly pushed me to do the same with pg-snap-anon and pg_query_guardian. And honestly, the EDB certification curriculum forced me to go much deeper into internals — monitoring, partitioning, connection pooling, FDWs — than I ever would have on my own.

8) What’s one PostgreSQL concept or feature you finally understood and felt proud of?

That lightbulb moment when something clicked, we all have one!

A pgvector and hybrid search. Building pgvector-docs-assistant — a local RAG system that answers PostgreSQL DBA questions using dense vector search combined with full-text search and Adaptive RRF scoring, running on PostgreSQL 18 — made me realise that PostgreSQL isn’t just a relational database anymore. The moment that clicked, it fundamentally changed how I think about what a database can do.