u/meatmick

I've started working with dbt and a cloud warehouse, where I'm thinking of moving from auto-incremented keys in favour of surrogate hash keys, both because auto-increment keys is not as much of a thing in cloud warehouses and also because hash keys are idempotent and much simpler to manage.

One thing that I'm not sure of yet is this: If the surrogate key is a hash of the business key, should I self-hash the foreign key references in the fact table builds, or should I do the usual pattern of left join on dims + coalesce to sentinel value if not found?

I can see the pros and cons of both methods.

Some pros:

• Fewer risks of fan-out in case of misshapen data (should be caught by dbt tests, but still)
• Increased parallelism because of fewer dependencies
• Simpler lineage
• Late-arriving dims, early-arriving facts are not an issue
• If the dimension happens to be massive, this can save compute time, therefore cutting costs.

Some drawbacks of self-hash:

• Reduced impact analysis clarity through the lineage because of no lookups. This can also be diminished via dbt docs
• You must ensure that you hash the same way (logical ordering and also natural keys formatting). A left-join lookup is likely easier to catch in case of a missed lookup (idk).
• Not exactly a drawback, but you probably want to left-join if you apply SCD2.
• No clear way to ensure proper fallback to the sentinel value if that is something used in the analytics layer

Over a span of 2 weeks, a colleague upgraded our codebase to go up 5 versions (up to v22) of Angular, and it cost just shy of 100k credits.

Around 15k of those credits were eaten from our 18k credit pool.

He used Claude Opus 4.8 high and 4.7 very early on (around an 85/15 split).

He went up, version by version, reviewing code along the way, and applying a few manual fixes here and there.

People bash Copilot for its cost, but considering how much consultants would have billed us to even look at the codebase, this was a great deal.