PostgreSQL
Relational modeling, indexing, and query tuning on production Postgres.
PostgreSQL is my default relational store. I design normalized schemas, write SQL by hand for the parts that matter, and use JSONB columns only where the structure genuinely is flexible. I lean on EXPLAIN ANALYZE more than I lean on guesswork.
How I work with PostgreSQL
I have used PostgreSQL across both the Node/NestJS and Spring Boot stacks — usually with TypeORM, Prisma, or Spring Data JPA, but I am comfortable dropping down to raw SQL when an ORM is doing the wrong thing.
Most of my Postgres work has been on transactional OLTP workloads — listings, billing, compliance audit logs — where consistency, foreign keys, and proper transactions matter. I have also used JSONB columns for genuinely-flexible payloads, but I prefer real columns + indexes wherever possible.
Operationally I have run Postgres on AWS RDS, configured backups + read replicas, written migrations with TypeORM/Flyway, and tuned indexes from `pg_stat_statements` output rather than gut feel.
PostgreSQL across business domains
Modeled compliance entities, audit logs, and reporting tables with strict FK relationships and check constraints.
Used PostgreSQL for transactional listing/agent/lead data with composite indexes powering filter-heavy search.
Backed billing/payment ledgers with Postgres, using row-level locking for safe concurrent updates.
Stored workflow state and audit trails in Postgres with materialized views for management reporting.
Real issues I resolved using PostgreSQL
Brought a slow report from minutes to milliseconds with the right index
A compliance reporting query was taking 30–90 seconds depending on data volume because the planner was doing a seq scan on a 12M-row audit table.
Read the EXPLAIN ANALYZE plan, designed a composite BTREE index matching the actual WHERE+ORDER BY shape, and ran `ANALYZE` to refresh statistics. Verified the planner picked the new index before merging.
Report runtime dropped to under 200ms, planner used the index in production immediately after deploy, and the team stopped working around the slow report.
Replaced flaky 'eventually consistent' counters with a single SQL UPDATE
A multi-step counter increment was prone to race conditions when two requests landed at the same time — totals would drift slowly over weeks.
Replaced the read-modify-write pattern with a single `UPDATE ... SET count = count + 1 RETURNING count` in one transaction. Added a unique constraint to prevent duplicate side effects.
Counter drift stopped completely, the bug class disappeared, and the code got simpler.
Migrated a 60GB table to a partitioned layout without downtime
An audit table had grown to ~60GB and vacuum + index maintenance were getting painful, with occasional long-running statements blocking writes.
Set up declarative range partitioning by month, backfilled in batches behind a feature flag, swapped reads/writes to the partitioned table, and dropped the old one only after a verification window.
Vacuum/maintenance windows dropped sharply, monthly partition drops made retention trivial, and the long-running statement alerts cleared.
Often used together
Have a PostgreSQL project in mind?
I am open to full-time and contract work where PostgreSQLis core to the stack. Let's talk about what you are building.