Database work is not selecting a popular engine and adding indexes after launch. It is preserving business invariants while data grows, requests overlap, schemas change, and dependencies fail. I approach database engineering as part of the system design—not as a storage detail.
The decisions that matter #
Model invariants before tables #
A schema should make invalid states difficult to represent. Before choosing columns, I identify entity identity, ownership, lifecycle, uniqueness, consistency boundaries, and the operations that must be atomic. This determines whether a relational model, document model, key-value store, search index, or combination is justified.
Design from access patterns #
Indexes are physical data structures with write, memory, and maintenance costs. I use query shapes, selectivity, ordering, cardinality, and expected growth to choose them. The goal is not “index every filter”; it is predictable latency for important operations without making writes and migrations fragile.
Treat migrations as production changes #
Safe migrations account for old and new application versions running together. Expand-and-contract changes, backfills with bounded batches, observable progress, reversible steps, and explicit locking analysis reduce the risk of turning a schema change into an outage.
Make concurrency explicit #
Transactions do not automatically prevent every race. Isolation level, lock scope, optimistic concurrency, idempotency keys, unique constraints, and retry behaviour must match the invariant being protected. Delivery semantics shape the data model; they cannot be patched in at the queue consumer.
Areas I work across #
- PostgreSQL schema design, query analysis, indexing, and operational patterns
- transactional boundaries and consistency models
- zero- or low-downtime migrations and data backfills
- event-driven systems, outbox patterns, and idempotent consumers
- database observability, capacity signals, backup, and recovery planning
- data ownership across services and API boundaries
Read what to decide before choosing a database, why delivery semantics shape a data model, my detailed guide to BM25 search ranking from first principles, and recent PostgreSQL writing in the engineering blog.
Database architecture in context #
The best database decision depends on the rest of the system. Caching changes consistency. Queues change delivery guarantees. Search indexes create derived state. Multi-region operation changes latency and conflict assumptions. A database engineer therefore has to reason about APIs, workloads, observability, deployment, and failure recovery together.
That wider view is part of my work as a CTO in Kolkata and systems architect. If you are dealing with scaling queries, unclear data ownership, risky migrations, or a backend whose correctness is difficult to explain, reach me at basakayush942@gmail.com.