For a while, “I know Postgres” meant I could design a few tables, write joins, and connect an application without upsetting it too badly. That is useful. It is not the same as understanding the database.
Building AlgoMind has been pushing me past that comfortable layer. Review queues, user-scoped data, metrics, and histories make the difference between a query that returns the right result and one that keeps doing so as the data grows.
Indexes are a conversation with the planner
I used to think of an index as a speed switch: add one to the columns in a filter and the query becomes fast. Now I spend more time with EXPLAIN (ANALYZE, BUFFERS), looking at what Postgres actually chose and asking why.
Sometimes the index is wrong. Sometimes the query shape is wrong. Sometimes the table is small enough that a sequential scan is exactly the sensible answer. The planner has opinions, and it usually has receipts.
Schema changes are product changes
Migrations are not just SQL files that make CI green. Defaults, constraints, backfills, lock time, and rollback behaviour all affect the application. I am learning to design them with the same care as an API change.
I am nowhere near done learning Postgres. That is the point. Databases get more interesting when they stop being a box under the API and start becoming a system worth understanding on its own.