added stripe billing to @ClickHamlet, first time doing it end to end: - free and paid plans, checkout + webhooks - usage meters: compute per GiB-minute, storage per MiB-hour - costs counted from the moment an account starts paying - the hour you upgrade is reported once, with idempotency keys on meter events first customer: me, at 100% off 😅

does it make sense to build a clickhouse offering on top of s3? last 30 days: $42.34 revenue at our prices, $51.78+ in aws (billing lags ~24h)

I didn't care about deployments when I started working on @ClickHamlet, it was an ugly bash script. Now that it's running for some users, it was time to add zero-downtime deploys: - releases are immutable and prepared before the switch - the controller leaves backends running when it exits, the next one adopts them - a systemd socket unit keeps the ports open while it restarts, so connections queue instead of failing - routers retry on a fresh connection if their pooled one breaks - idle and drain timers live as annotations, so they survive the restart Deployed with queries running, nobody noticed

Prototyping is cheaper than ever, so I tried to imagine the simplest possible ClickHouse service. The result is a side project called ClickHamlet. You run: clickhouse client --host cloud.clickhamlet.com --secure --user <name> --password And that's it. No sign-up form, real ClickHouse in the cloud.

spent the weekend making my side project's query path faster, measuring every step and re-running all of it on one machine: 443 → 2,209 queries/s through the router (5×) 2.39 → 0.31 ms of controller CPU per query (7.7× less) no single big fix, just small changes that add up

imagine running your own dedicated ClickHouse cluster like this: