This is an interesting approach especially if you factor in that re-minting a key is usually a lightweight task compared to what most API calls have to interact with.
If the re-minting happens transparently with a user interaction then you spread out some of the request velocity that can come with that (if you're operating at a large enough scale for it to matter for this to be a concern).
Calendar Versioning (CalVer, YYYY.Release.Patch) fulfills the same need and you can see it in practice with Jetbrains (e.g. the latest version of IDEA is 2025.3.6).
The only difference is Jetbrains uses YYYY.R for marketing, see: "What's new In 2025.3"[1]
>But before I did so I researched first. I asked a few instances to analyse the project in terms of gains of complexity, stability, testability, etc., and while (obviously) stability would drop (no types in Ruby) it’s not that awful (Sorbet has types in Ruby!).
Is it not a rage-bait argument to say that not having types implies less stability?
Ah, I was using GH's webui instead of downloading to view the PDF and it stopped loading at slide#47...rereading it now paints a much better picture. Thanks!
If I followed, Rust's memory safety guarantee means sacrificing roughly ~3% performance with some worst case paths being ~15% (compared to C++ performance)?
Is it too much to ask for a not-vibe-coded billing system? In my opinion, we need better systems to hold these companies accountable as I don't believe the $20/dispute they're paying means much given how common other customers are complaining about billing irregularities just in this thread alone.
OP's ask was: "Is this another one ... where open source is used more as a marketing gimmick"
My original comment wasn't intended to indicate that there is an obligation to provide support. The deliberate choice to: a) not offer paid support for open-source deployments, and b) sunsetting the Kubernetes deployments in favor of their cloud version, is a signal that shows PostHog doesn't /really/ want you to be running the software in a self-hosted manner.
Just look at the "Open-source hobby deploy" (from the README in git) which calls out that it "should scale to approximately 100k events per month" but their cloud offering gives you 1 million events per month for free. What is the point of the hobby "deploy"?
Back to OP -- my answer is yes, this is a source-available service that you can modify and play around with locally. The source and documentation behind the operations of PostHog aren't available.
Fairly accurate, you can only get support if you're using their cloud product.
"We no longer support paid, open-source deployments and it is no longer possible to buy licenses for self-hosted versions - we instead recommend migrating to PostHog Cloud." - from: https://posthog.com/docs/self-host
What a wild story...it's crazy to think that we have 1080p emulator video (https://www.youtube.com/watch?v=EufWGcflwjQ) without having the underlying rom ever ending up on the internet.
If you're at a point of spending $1.6M to transition objects from one class to another and spending millions per month in storage costs -- you need to have a real conversation about if storing your data in a vendor-locked cloud is the right path forward. S3 isn't the only option, MinIO + dense storage is one viable option if your spend is high enough to justify running MinIO. Backblaze is another.
List price of Backblaze:
$0.005/GB - Base Storage
$0.01/GB - Egress (Use a data partner to bring this down to $0)
Thanks for the feedback -- agreed on the reserved capacity being an anti-pattern.
For the third point, what I've suggested in the past to push your artifacts into the region (since that's free) and then pull it down from S3. This lets you only incur S3 costs which tend to be cheaper then NAT data transfer costs (assuming you're using a VPC endpoint or equivalent).
I recently published this article and it's been weird to see how divided the community it is on this.
It feels that half of my inbox is people yelling "we've been running this in production", the other half yelling "this is this worst thing to do in the cloud next to leaving S3 buckets open".
I'd love to know your sentiment if you have one as I didn't expect to hit such a nerve.
Could you share why?