Starting PostgreSQL After Two Years of MongoDB

I want to be upfront about this one: this isn't a "how I shipped a Postgres feature in production" post. It's a "here's what switching mental models actually feels like" post, written while I'm still in the middle of it.

The Problem

Almost all of my production experience is MongoDB - schema-flexible documents, references instead of foreign keys, aggregation pipelines instead of joins. It's worked well for the projects I've built (Teams' chat/notification data, ArtGlimpse's catalog, ERP records). But relational databases are still the backbone of a huge share of backend roles, and "I've only ever used MongoDB" is a real gap when a job wants SQL, migrations, and normalized schemas.

So I started a structured 30-day plan to actually learn PostgreSQL properly - not just copy syntax from docs, but build the muscle for relational thinking.

The Approach

A few things I did differently this time compared to past "let me learn X" attempts that fizzled out:

• Compared concepts directly against MongoDB, not from zero. Every new Postgres concept, I ask "what's the Mongo equivalent, and where does the analogy break?" Foreign keys vs. ref fields was an easy mapping. Joins vs. $lookup aggregation stages was a good one too - similar goal, very different cost model. Where it doesn't map cleanly (multi-table transactions, strict schemas, JOIN performance planning) is where I'm spending the most deliberate time.
• Structured the 30 days around building something small, not just reading - normalized schema design, writing actual queries against realistic fake data, then intentionally denormalizing a piece of it to feel why you'd trade normalization for read performance, since that's a real tradeoff I've already had to make on the Mongo side (I recently dealt with a cross-database populate problem that we solved with deliberate denormalization plus async sync - so the tradeoff itself isn't new to me, just the SQL vocabulary for it).
• Being honest about where I am. I'm not putting PostgreSQL on my resume yet. A line item with no project behind it is weaker than no line item at all - it invites a question in an interview I can't yet answer with a real example. I'd rather add it once there's an actual project, even a small one, backing it up.

Where I'm At

Comfortable with schema design, basic to intermediate joins, and indexes. Still building real intuition around query planning and when a join actually costs you versus when it's fine - that kind of judgment mostly comes from hitting slow queries yourself, not from reading about them.

What's Next

The plan is to rebuild a small piece of one of my existing projects - probably a reporting/analytics slice - on Postgres, specifically to hit real tradeoffs instead of tutorial-clean ones. Once that exists, this post gets a follow-up, and PostgreSQL goes on the resume for real.

If you're coming from Mongo and thinking about picking up SQL: the syntax is the easy 20%. The mental shift - designing for normalized structure and letting the query planner do the work instead of denormalizing everything up front - is the actual learning curve.