I'm a database and backend engineer with about 8 years of experience running production data systems: PostgreSQL, Aurora and RDS, SQL Server, Snowflake and the pipelines between them. No account manager or junior analyst sits between you and the person reading your evidence.
Most of my work starts with two questions: why is this slow, and why did it break? That has meant reading execution plans to explain why the same query chooses an Index Scan in development and a Bitmap Heap Scan in production, tracing a production RDS failover back to shared_buffers set larger than the instance's memory, and choosing between BRIN and B-tree indexes based on how a table is actually written.
pgoutput, Debezium Server to S3, Snowpipe ingestion, and managing replication-slot and WAL-retention risk with max_slot_wal_keep_size and per-slot lag alerting.I have built semantic-search services that store Sentence-BERT embeddings in PostgreSQL with pgvector, so I look at AI features the way I look at any other workload: what the index does, what the planner chooses, and what happens to latency and recall as data and filters grow. I write about the trade-offs that show up in production, such as HNSW vs IVFFlat and filtered vector queries that silently return fewer rows. See pgvector performance reviews.
I also use AI in my own work, with clear limits. It helps me summarise evidence, draft and cross-check. It does not decide findings, raise confidence or recommend production changes; I verify every finding against your evidence. Your evidence is never sent to an AI service without your written consent. Why the human part matters: what AI misses in a production PostgreSQL diagnosis.
pg_monitor role and strict timeouts.PostgreSQL is my primary focus, especially on AWS RDS and Aurora. I take on SQL Server, pgvector, Snowflake and OLAP/analytical work where the problem matches real experience. If it does not, I will say so.
Your team describes the symptom and runs agreed read-only evidence collection. I review the workload, write ranked findings with risks and validation steps, then walk through the recommendations with your team. The work is async-first, with scheduled review calls. Scope, price and delivery date are agreed in writing before work starts.
I describe my experience without employer or client names, figures or data. Proprietary data is never used as public proof. Public examples use generated data and measured lab runs. Client work is shared only with explicit, written permission.