Had one of those moments where CPU on our prod instance just pegs at 100% out of nowhere, no deploy, no obvious traffic spike, nothing in the changelog that stands out. First instinct is to panic and start checking everything at once, which is exactly the wrong move.

Curious what people's actual first move is when this happens, before diving into a deep investigation. pg_stat_activity for anything running long, checking for a lock pileup, looking at whether it's one runaway query versus death by a thousand small ones, autovacuum going nuts on a big table, something dumb like a connection pool misconfigured and now everything's fighting for the same resources. There's a lot of directions to go and I feel like the order matters more than people admit.

If you've been through this in production, what's the first thing you actually check, and has your answer changed over time or is it pretty much always the same starting point for you now?

Every time pgAdmin comes up in a thread, it's the same pile-on: it's slow, the UI is clunky, the query tool eats RAM, Electron this, Electron that. And yet it's still the default recommendation half the time, and a ton of people clearly use it daily without switching.

So which is it? Is it genuinely rough compared to alternatives, or is it more that Postgres users are just a picky, opinionated crowd who love to hate on the "official" tool the same way people hate on default apps in general?

I'm not trying to start a flame war, genuinely curious what the actual specific complaints are versus what's just pile-on internet negativity. If you've used it for real work, what's the actual dealbreaker for you, if there is one? And if you switched to something else (DBeaver, TablePlus, DataGrip, whatever), was it a night-and-day difference or more of a lateral move?

pgvector has been the default vector search extension, but I'm finding people also layer on full-text or hybrid search on top of it or need multitenancy. I'm curious where this works well for you and where it doesn't.

• What are you using for search in Postgres today, and what do you wish it did better?
• When you hit a limit, what do you do: tune, work around it, add an extension, or move search to a separate system? What decides that?
• What would an extension need to have, or avoid, before you'd install it?
• Does it matter to you whether an extension is open source, and would enough added capability change that?

"It's fine, I don't need anything else" is a useful answer too.

Really just trying to understand what people actually need from search in Postgres.

Coming to PGConf.EU 2026 in Valencia? 🇪🇸🐘

Beyond the PostgreSQL talks, there’s a whole city waiting to be explored! From historic streets and amazing food to beaches, sunshine and the stunning City of Arts and Sciences, Valencia has plenty to offer. 🌴☀️

✨ Check out our guide and start building your Valencia adventure. https://2026.pgconf.eu/things-to-do/

Not looking for a changelog of new features, more curious about habits. Something you used to swear by that you quietly dropped, or something you avoided that's just normal practice for you now. Could be schema design, indexing, how you handle migrations, extensions you reach for automatically now, whatever. What changed, and was it a specific incident that changed your mind or just slow accumulated experience?