🇫🇷 Bonjour, Paris! 🥖 Tiger Cloud has officially landed in the AWS Paris region (eu-west-3)! Your databases can now enjoy fresh croissants, fine wine, and significantly lower latency. Liberté, Égalité, Postgré. Vive le tigre!

New Arrested DevOps: I had Sylvain Kalache (@sylvainkalache, runs the AI lab at Rootly) on to talk AI and incidents: what AI SRE tools are good at, and what happens to responders when the robot takes every easy incident. arresteddevops.com/ai-and-in…

I used to post on social media all the time about tech and DevOps culture and all that kind of stuff, and now it seems like the only thing that I want to post about is lifting weights. lol

Hit a new PR today … 350lb deadlift. This was set 5 of 3 reps…tried to squeak in a 4th one but it wasn’t happening 😂

Hacking away with @TimescaleDB for @codetv_dev

In a benchmark against Ignition’s existing SQL Historian on Postgres, the new Enterprise Historian Module for TimescaleDB ingested 10x more data, queried it 10x faster, and used 10x less storage. Full SQL access throughout. Travis Cox (@InductiveAuto) and Doug Pagnutti (@TigerDatabase) walk through how Ignition and TimescaleDB fit together, plus TimescaleDB for Ignition: unlimited tags, one price, optional HA cluster at no extra charge. Thursday Oct 22, 9am PDT / 4pm GMT. Register and you'll get the recording either way. tsdb.co/ignition-webinar-x

Storing vectors is easy. Retrieving the right evidence is harder. Introducing searchgres.js: BM25, semantic + hybrid search in Postgres, with hierarchy, metadata, regex + time filters. Filtering belongs inside retrieval. tsdb.co/searchgres-x

Really enjoyed joining Colby Clegg, CEO of @InductiveAuto, on the Ignited podcast. I've long admired what they've built with Ignition: an open, flexible platform that has transformed how industrial teams build and deploy software. We talked about our growing partnership, why @TimescaleDB is such a natural fit for industrial workloads, and how we're bringing the two together with the new Ignition Enterprise Historian. Excited about what this unlocks for industrial engineers! piped.video/watch?v=di0ddOuC…

Marino Wijay (@virtualized6ix) on the show: "Tech has been the largest accounting hack ever." His case: VCs hedging across five companies on the same non-problem, and a tax structure that rewards hiring tech people either way. arresteddevops.com/wtf-is-go…

"You're comparing your own friction points with everyone else's highlights." @DevOpsJacquie on why every launch makes it look like everyone else learned the new thing last night. From the episode: arresteddevops.com/meaningfu…

New on Arrested DevOps: @DevOpsJacquie and I talk about keeping meaningful control over the tools you depend on. Know what they're tied to, verify they do the job, and have a realistic way out. arresteddevops.com/meaningfu…

pgvector 0.8.7 fixes CVE-2026-103484. Any database user who can create an IVFFlat index can write out of bounds in the backend, which can get you to arbitrary code execution. Every version through 0.8.6 is affected. thebuild.com/blog/the-vector… Upgrade. That part’s easy. Christophe Pettus spends the rest of the post on the harder questions, mostly: who can actually reach this in a real deployment, and what does “a user who can create an index” mean when your app has one database role that does everything. I’ll argue for consolidating onto Postgres in most rooms I walk into. This is the invoice that comes with that position. Your attack surface is the union of every extension you installed. Each one has its own release cadence, its own maintainer bandwidth, and its own relationship with the word “soon.” Core Postgres has thirty years of security process behind it. The extension you added in a sprint last spring might have one person with a day job. That’s a tradeoff I’ll still take. It’s not a free one. Do you know the installed version of every extension in your production cluster right now, or are you about to go find out?

Your nightly backup is evicting your working set and you probably haven’t measured it. clickhouse.com/blog/direct-i… A backup reads every byte of a live database off the same drives answering your queries. By default Linux caches all of it, in case someone asks for those bytes again. Nobody will. To make room, the kernel throws out pages Postgres was about to use, and the next query goes to disk. Their test box: 48 vCPU, four NVMe drives, 467 GB database under live load. The buffered backup evicted all 40 GiB of a warm table that was sitting idle and not involved in the backup at all. With direct I/O: evicted nothing, finished in 71 seconds, roughly two thirds less latency impact, about 14% less CPU. The catch is what makes this cool. Direct I/O also turns off kernel readahead, so a small read keeps one drive busy while three sit idle. You have to size each read to span the whole RAID0 stripe and scale reader count to the hardware. The flag alone makes things worse. Nice writeup. Go look at what your backup window does to your cache hit rate.

I got to help with the pg_vectorsearch launch, our new OSS Postgres vector index. The days were long but the weeks were short, very excited to have this out there. 100M vectors on a 128 GiB machine: built in 1h40m, 99% recall at 21 ms. pgvector’s HNSW couldn’t even build there. Lots more impressive stats in the post, along with a deep dive of the architecture for how we got the results: tigerdata.com/blog/announcin…

Someone built a Postgres index advisor, then built every index it recommended and timed the queries. Including the ones that embarrassed the tool. prateek-arora.github.io/2026… 179 measured recommendations. 128 at least 15% faster. 32 at least 5% slower. Seven more than twice as slow. The worst estimated 91% cheaper and measured 0.93 seconds to 7.3 seconds. The reason is structural. HypoPG validates a suggestion by asking the planner if the hypothetical index lowers the cost. But the planner’s row estimates are often the reason the query was slow in the first place. You’re asking the confused party to grade its own confusion. This is the part of the optimization treadmill that’s hardest to see from inside it. You ship a change, the estimate improves, the dashboard looks better for a while, and you never find out whether the fix was real. At Tiger Data we talk a lot about the difference between operational friction and architectural friction. What to test it cheap? If you can’t measure whether your last five optimizations helped, you don’t yet know which kind you have. Estimates are free. Measurements are not. Spend accordingly.

The "software is dead" people are missing sufficient empathy. It's a natural conclusion as a software builder, someone fascinated by computers. But only 0.5% of people are "software engineers." The remaining 99.5% very well may prefer non-generative ux, even in the long-run.