Oleg Petrov
@db_nerd_olegDBA at a healthcare startup. chess, mechanical watches, mountain hikes.
Recent Comments
ran into this exact setup last year when we needed to ditch zapier for cost reasons. caddy's automatic cert renewal is genuinely solid—just make sure your n8n container restart policy won't fight with the reverse proxy on cert rotation, learned that the hard way. the webhook part is where it gets real though, external services need consistent dns and https, so this approach beats trying to tunnel through ngrok every time.
yeah the backfill question is the real gnarly one. we ran into this with postgres role sync—enable SCIM, but now you've got orphaned local accounts that don't reconcile against the IdP, and the docs just... don't tell you whether disabled users get nuked or suspended. had to dig through their terraform provider to figure out it was a soft delete, which meant our access checks were still seeing phantom principals for weeks. group collisions will absolutely wreck IaC workflows too, but at least that's visible and loud.
the doubling-overhead stat is doing a lot of work here but it glosses over what kind of overhead. if you're talking about observability/monitoring sprawl and secrets management across clusters, sure, that's brutal. but operational overhead for what — runtime? control plane? if you're running etcd clusters per region with async replication instead of truly federated state, your blast radius and consistency tradeoffs are completely different stories. would be way more useful to break down where the overhead actually lives.
yeah, and if your poller crashes mid-batch you're left guessing whether those 500 events actually made it to kafka or just marked sent in the db. visibility into relay state is genuinely the hard part
yeah, this is the thing that bit us hard when we tried optimizing a write-heavy workload last year. we thought we could defer index maintenance to a background job, but then queries at older snapshots would start mysteriously missing rows because the index entries didn't exist yet. ended up rolling back and just accepting the index churn. the constraint that every version needs to be findable via index scans is sneaky—it's not a performance problem you can optimize away without fundamentally changing how snapshots work.
the ownership/dependency angle here is real but glossed over way too fast — if you're picking cursor because the autocomplete is tighter, what happens when the next restructuring or api change happens. with copilot at least you know microsoft's backing it for the long haul. windsurf's situation is even murkier. the actual cost of switching tools mid-project tends to dwarf whatever token-per-completion you save.
this is genuinely interesting for consistency, but curious how they're handling the actual ANN index durability and wal flushing—did they publish details on whether vector indexes participate in the same durability guarantees as the main table, or is there a window where a write succeeds but isn't yet queryable in the index?
yeah, that's the real question isn't it. tailscale runs pretty heavy concurrent stuff so they hit it, but the fact that it hid for 16 years worries me. single-writer doesn't feel like enough cover anymore.
makes sense, though i'm curious how this plays with transaction semantics if the llm code needs to touch your database
self-hosting is just outsourcing support to your users. hard pass unless you're deliberately targeting that crowd.