Newest first, grouped by year. Search or filter by topic.
KC Star V5 climbs the org chart in a single view - employee to office to region to organisation - and a stored procedure that materialises the rollups. Commission analysis and quote-to-delivery ratios fall out of the same hierarchy.
KC Star V4 tracks lineage two incompatible ways depending on which build you run - a normalized FactLineage graph in the root file, a denormalized DataLineage string in the version folder. The fork is real, and it is a clean case study in when a graph pays and when a string is enough.
V3's rewritten CreateAggregatedFacts expires every aggregate and rebuilds them all from scratch on each run. It is blunt, it is correct, and the trade between rebuild-it-all simplicity and incremental cleverness is one KC Star kept relitigating all the way to V8.
KC Star V9 Simplified's schema is four permission tables and five seeded personas - full access, online-only, store-only, delivery-and-quotes, commission-only. GetFilteredSalesData takes an employee and returns exactly their slice. Permissions you can read in one table.
KC Star V2's measure formulas read like window functions - SUM(...) OVER (PARTITION BY SaleType) - but the implementation is plain GROUP BY. Here is how CreateAggregatedFacts actually builds the aggregates, and why the formula strings deliberately lie.
Fusing per-employee permissions with per-change recalculation multiplies work by headcount. KC Star V9 ships both the naive per-employee implementation and an optimised per-permission-group one that collapses a thousand employees into seven groups. The most important design call in the version.
KC Star V1 has no ETL job and no application code. Two PostgreSQL triggers explode sales into dimension rows and version them on change - and the gaps between what they do and what I claimed they do are the most instructive part of V1.
KC Star V8's intelligence lives in one table - MeasureDimensionDependency - mapping which measures each dimension drives, with a DIRECT/INDIRECT/AGGREGATION type and an impact weight. Here is how the map is built, seeded and generated, and the priority formula that reads it.
In KC Star V7 every batch run gets a generated id, a log row, a processed count and a time budget it must finish inside. Here is the orchestrator that ties it together, the per-batch exception isolation - and a variable-shadows-column bug I shipped in the middle of it.
KC Star V6 decides access by comparing a single integer. An employee's highest LevelOrder against the level being requested - Global sees everything below it, an employee sees only themselves. Coarse, cascading, and a deliberate trade against per-object ACLs.
KC Star V5 pretends one PostgreSQL instance is two databases, joined by a single un-enforced integer. CrossDatabaseFact carries two reference keys at once, and eight windowed measures value a single sale at every altitude of the org chart.
KC Star V4 puts a DataQualityScore on every dimension and fact, defaulting to a perfect 1.0 and downgrading only on evidence. Here is the opt-out philosophy, the assessment procedures behind it, and the one query that finds every row the warehouse doesn't quite trust.
An average with no denominator is a number you can't defend. KC Star V3 adds a FactCount column to every aggregate - how many facts went into this rollup - turning each stored aggregate into something you can audit rather than just trust.
After nine versions of accumulating ambition, KC Star V9 Simplified does the rarest thing - it takes features away. No permission groups, no group cache, just direct permission lists. The README recommends starting here. Kicking off the series on the version I would actually deploy.
To compute per-SaleType aggregates, KC Star V2 lifted one dimension out of the row store and made it a real column. Here is the renumbering it forced, what it did to the version hash, and the honest tension of un-inverting one attribute in a schema built on inversion.
KC Star V9 fuses V8's intelligent recalculation with V6's permission-aware calculations - and folds the employee and their permissions into the very hash that decides what to recompute. Kicking off the series where two engines meet in one version, and complexity meets its reckoning.
The heart of KC Star is two tall, narrow tables and two lookup tables. Here is how a sale becomes seven dimension rows and a handful of measure rows, and how a view pivots them back into something you can read.
Every version through V7 rebuilt all the measures when a dimension changed. KC Star V8 recalculates only the ones that actually depend on what moved - dependency analysis, selective recalculation, and claimed 60 to 80 percent less work. Kicking off the intelligent recalculation series.
The per-row triggers that ran KC Star for six versions stop scaling at high volume. V7 turns them off and moves fact generation into an explicit batch pipeline. Kicking off the ultra-scale series - batch processing, feature flags, automated monitoring.
KC Star V6 layers role-based access control onto the org hierarchy - eight permission types, five hierarchy levels, and grants that expire. Kicking off the series where the warehouse learns that not everyone should see every number.
KC Star V5 gives the sales star a sibling: a full organizational hierarchy — organisation, regions, offices, personnel — with its own dimension rows, its own fact rows, and its own SCD2. Kicking off the series on the version where one star became three.
Through V3, KC Star assumed every number it was fed was true. V4 stops assuming - adding data quality scores, lineage, and performance monitoring so the warehouse can say how much it trusts its own data. Kicking off the data governance series.
KC Star V2 leaked aggregate rows because base facts and rollups shared one table. V3 gives aggregates a dedicated SalesAggregationFact table with its own SCD2 - and the fix is as much about what SalesFact loses as what the new table gains.
KC Star V1 declared eight measures and computed four. V2 computes all eight - base measures and aggregates together in a single SalesFact table. Kicking off the series on the version that made the warehouse analytical, and started the trouble that V3 had to fix.
What if dimensions and measures were rows instead of columns? Introducing KC Star, a PostgreSQL data warehouse I evolved through nine versions, starting with the inverted foundation - SCD2 history, SHA-256 fingerprints and time travel included.
