SQL

1 / The Constant Underneath

SQL is not a technology I adopted at a specific moment — it is the constant that underlies almost every project I have built. From relational schema design in Trajectory to vector similarity queries in Phoenix, SQL has been the interface through which I interact with persistent data.

2 / Schema Design and Indexing

Most of my SQL experience is with PostgreSQL, though I have also used MySQL, MongoDB (which has its own query language), and SQLite for embedded local persistence. The engineering challenges have centered on schema design decisions: choosing between normalized relational models and denormalized JSONB document fields, designing indexes that support actual query patterns rather than theoretical best practices, and handling multi-tenant data isolation through row-level filtering.

3 / Beyond CRUD

The most interesting SQL work came in contexts where simple CRUD was not sufficient. In Phoenix, SQL queries combined relational WHERE clauses with pgvector cosine distance operators — effectively mixing traditional filtering with vector similarity search in a single query. In Trajectory, pessimistic locking with `SELECT FOR UPDATE` prevented booking race conditions in concurrent application pipeline state updates.

4 / Migrations and Discipline

Working with Flyway for version-controlled database migrations taught me that schema evolution is not something you do ad hoc. Every migration is a contract change, and automating migrations through CI/CD pipelines eliminates the manual drift that causes production schema mismatches.