{"id":50468977,"title":"Show HN: Bringing Pulumi's 20x faster journaling to DIY back ends","points":2,"user":"unconscionable","time":1794497270,"time_ago":"4 hours ago","type":"link","content":"

Hey HN! I created a fork of pulumi to explore how we can bring Pulumi's state-journaling architecture to DIY and self-hosted state backends. It's available at https://github.com/ebrake/pulumi-journaling

Background: Pulumi recently detailed their journaling architecture (https://www.pulumi.com/blog/journaling/), which changes how state snapshots are synced. Instead of uploading a massive full state snapshot on every operation (which gets sluggish for large stacks), it streams incremental state operations in parallel, achieving up to 20x speedups.

Journaling optimization has historically been tied to Pulumi Cloud. This repo brings similar state journaling and crash-recovery mechanics (like tracking epoch manifests) that works for file/S3/DIY backends.

I measured these timings against standard OSS pulumi using a GCS rapid bucket (https://docs.cloud.google.com/storage/docs/rapid/rapid-bucke...) which has low latency and is inexpensive given the amount of storage usage with a state bucket. Speedups become more effective the more resources you have.

  Resources | Updated | Without journaling | With journaling | Speedup\n\n  ----------+---------+--------------------+-----------------+--------\n\n       24   |  15     | 19.66              | 1.69            | 11.6x\n\n       91   |  50     | 71.36              | 2.12            | 33.7x\n\n      152   |  50     | 70.97              | 1.91            | 37.1x\n

\nWould love feedback from anyone else working on IaC state management, concurrency, or crash recovery patterns!","url":"https://github.com/ebrake/pulumi-journaling","domain":"github.com","comments":[],"comments_count":0}