PostgreSQL for Everything | Build or Be Replaced

Today: PostgreSQL for Everything | Don't Paste the AI, please | Casio F-B100W-1A Episode date: 2026-08-20.

Transcript

JOSH: It's Thursday, August 20. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today's theme is simple. AI doesn't replace builders. Lazy copy-paste does. JOSH: Stick around — Erik's got an AI pro tip at the end about writing agent instructions that don't wreck your repo. [pause] JOSH: First headline. Hacker News is fired up over PostgreSQL for Everything. Erik, are people overthinking their databases again? ERIK: Usually, yes. Postgres is boring in the best way. If your app needs relational data, JSON, queues, search-ish behavior, and sane backups, Postgres handles a lot before you need five different systems and a diagram nobody wants to maintain. JOSH: Second one. Don't Paste the AI, please. A site that politely calls out lazy AI replies is going viral. Is that fair? ERIK: Completely fair. If you paste raw AI output into a team thread with no context, you didn't do work. You made someone else review a robot's homework. JOSH: Third headline. OpenRouter is joining Stripe for payments and billing across its model marketplace. Why does that matter? ERIK: Because model routing is becoming normal infrastructure. When a marketplace pushing traffic across 400-plus models plugs into Stripe, that's not a toy anymore. That's a utility bill with APIs. [pause] JOSH: Let's start with Postgres. The headline says PostgreSQL for Everything. That sounds like a developer argument waiting to happen. ERIK: It is, but it's a useful argument. Postgres has become the default answer for a reason. You get transactions, indexing, extensions, JSONB, listen-notify, full-text search, replication, backups, and a huge operational base. That means fewer moving parts. JOSH: But people love adding moving parts. ERIK: Duuude, yes. Somebody builds a CRUD app and suddenly they've got Postgres, Redis, Elasticsearch, Kafka, ClickHouse, and a cache invalidation problem they invented on Tuesday. [beat] ERIK: The issue isn't that those tools are bad. They're great when you actually need them. The issue is starting with them because the architecture diagram feels more serious. JOSH: How do you decide when Postgres is enough? ERIK: Start with the pain. If writes are safe, reads are fast enough, backups are boring, and the data model isn't fighting you, keep going. Don't split systems because a blog post made you feel under-engineered. JOSH: That sounds very anti-hype. ERIK: It's pro-shipping. ScanBrief scored 84 items across 56 sources today. That system is not impressive because it has fancy storage. It's useful because it collects, scores, ranks, and gets the brief out. The job is the output. JOSH: Where does Postgres fit in your own stuff? ERIK: I use boring storage anywhere boring storage wins. Telemetry is a good example. PrimeBus is NATS at the event layer because messages need to move fast between agents. But the records, state, audit trails, and summaries don't need some exotic thing. They need to be queryable when something breaks at 2:00 AM. JOSH: So NATS for movement, Postgres for memory? ERIK: That's a good way to say it. NATS is the nervous system. Postgres is the notebook. Don't make your notebook a distributed consensus science project unless you're being paid to suffer. [beat] JOSH: Where do teams mess this up? ERIK: They confuse future possibility with current need. "What if we need massive horizontal partitioning?" Cool. Are you at that point, or do you have twelve users and a Docker Compose file named final-final-v3? JOSH: Wait, really? ERIK: All the time. And the funny part is, Postgres will carry more than people think. The operational maturity matters. Backups, migrations, permissions, read replicas, tooling. That boring stuff saves you. JOSH: Does AI change that decision? ERIK: It makes boring choices better. Agents are really good when the system has clear contracts. SQL schema, migrations, logs, tests. Claude can inspect a failed migration and reason about it. It can write a query. It can compare expected rows to actual rows. Give it seven loosely connected services and a half-working queue setup, and now the agent is guessing through fog. JOSH: So simpler stacks make better agent targets. ERIK: Exactly. Agentic workflows reward clarity. PrimeBus has 140 distinct projects emitting telemetry. That only works because the event shape is consistent. If every project invented its own little reality, Gandalf would block everything and I'd deserve it. [pause] JOSH: That brings us right into Don't Paste the AI. The page basically generates a polite reply saying, hey, don't just forward AI text at me. Is this a cultural problem now? ERIK: Yes. AI made it cheap to produce words. It did not make those words automatically valuable. JOSH: That's going on a mug. ERIK: It should go on every pull request template. The problem is when people use AI as a substitute for thinking instead of a tool for building. If you ask Claude for an answer, then paste it with no judgment, you're just outsourcing the mistake. JOSH: What's the right way to use it? ERIK: Bring context back. Say what you asked, why you asked it, what you accepted, what you rejected, and what still needs human review. That turns AI output into engineering work. JOSH: Give me an example. ERIK: Bad version: "Claude says we should add Redis." That's useless. Better version: "I asked Claude why the queue stalls under retries. It found duplicate job locks in this function. Redis was one option, but the simpler fix is making the Postgres lock idempotent. Here's the patch and test." Now we're talking. [beat] JOSH: So the issue isn't AI writing. It's people hiding behind it. ERIK: Exactly. Don't paste the AI. Paste your decision. JOSH: That's the line. ERIK: It's the only line that matters. I use Claude all day. I have 12 agents in the Bobaverse fleet across Neo, Homer, Bill, Echo, Gandalf, Claude and GPT. They write code, review code, inspect logs, and file fixes. But the system has guardrails and ownership. JOSH: This is where PrimeBus comes in. ERIK: Right. PrimeBus auto-merger has run 2295 attempts since 2026-06-05: 1507 merged, 788 blocked by Gandalf, 0 escalated to Erik. That's the story. Not "AI wrote some code, trust it." The story is the blocked count. The guardrails caught what shouldn't ship. JOSH: That's wild. Zero escalated to you? ERIK: Yep. And that doesn't mean everything was perfect. It means the workflow had enough checks to avoid waking me up. Tests, reviews, scoring, merge rules, and Gandalf being a pain on purpose. JOSH: Gandalf is the strict one? ERIK: Gandalf says no. That's the job. Every good AI build needs a no layer. People get excited about agents that can do things. Fine. But where is the agent that stops them? JOSH: That's a very different pitch than "AI intern." ERIK: I hate that phrase. Interns learn. A model predicts. Treating it like a person causes weird decisions. Treat it like a fast pattern engine attached to tools. Then wrap it with logs, tests, permissions, and rollback paths. JOSH: Where does the lazy copy-paste show up inside companies? ERIK: Email, tickets, design docs, incident summaries. Somebody pastes a beautiful paragraph that says nothing. It sounds professional and contains no decision. That's dangerous because it feels done. [beat] ERIK: In automation work, that's how you get fake runbooks. They read nice, but when the router is down, nobody knows what command to run. JOSH: You'd rather have ugly and useful. ERIK: Every day. Give me "check BGP neighbor, run show ip bgp summary, compare expected ASN, restart session only after confirming maintenance window." That's useful. Miss me with the paragraph about ensuring robust network reliability. JOSH: How should teams call it out without being rude? ERIK: Ask for the missing human part. "What did you verify?" "Which option are you recommending?" "What should we do next?" That makes it about accountability, not dunking on someone. JOSH: And if you're the one using AI? ERIK: Label it. "Drafted with Claude, edited by me, verified against logs." That's honest. Also, don't submit anything you can't explain. If you can't defend the output, it isn't yours yet. [pause] JOSH: Third story. OpenRouter is joining Stripe. The summary says OpenRouter is embedding Stripe billing into its AI model marketplace, with 400-plus models and a 10 million developer user base. Why should builders care? ERIK: Because the AI stack is turning into normal software plumbing. Model choice used to feel like picking a favorite chatbot. Now it's routing, billing, observability, fallback, latency, and cost control. JOSH: So more like cloud infrastructure. ERIK: Exactly. You don't say "we use compute." You say AWS, Azure, bare metal, Kubernetes, whatever. Same with models. Claude for code reasoning. GPT for certain structured tasks. Smaller local models when cost matters. OpenRouter sits in that routing layer. JOSH: And Stripe handles the money layer. ERIK: Payments are boring until they break. Then they're the only thing anyone cares about. If you're brokering model calls across providers, you need billing that doesn't turn into a spreadsheet crime scene. JOSH: Spreadsheet crime scene feels specific. ERIK: I've seen things. [beat] JOSH: How do you think about model routing in your own systems? ERIK: Task first. Model second. For code review, I care about reasoning and diff awareness. For summarizing ScanBrief items, I care about consistency and cost. For email-reactor, I care about following instructions exactly because client requests can be messy. JOSH: So you don't just point everything at the biggest model. ERIK: No. That's how you light money on fire politely. Bigger models are great when the task needs them. But if you're classifying email intents or turning a ticket into a structured JSON payload, you may not need the heavyweight every time. JOSH: Where does this get hard? ERIK: Evaluation. People switch models based on vibes. Bad idea. You need test sets. Real prompts. Expected outputs. Failure categories. If model A saves 40 percent but quietly breaks invoice parsing, you didn't save money. You bought a support queue. JOSH: That sounds like something PrimeDash would show. ERIK: PrimeDash shows me what's running, and there are 145 services on the production server right now. That number matters because you can't keep that in your head. Once AI is touching that many surfaces, you need dashboards, traces, retries, and kill switches. JOSH: Kill switches for models? ERIK: Absolutely. Provider down? Route around it. Bad output spike? Stop using that route. Cost spike? Throttle it. Prompt injection showing up in an email? HumanRail that thing or block it. JOSH: Is this where small teams can compete? ERIK: More than ever. A small team that understands automation can look bigger than it is. Not by pretending. By building systems that do the boring parts correctly. ScanBrief ranks the tech signals. Build or Be Replaced turns that into episode 92. PrimeBus watches the code. email-reactor handles client changes. That's not magic. That's pipes connected to judgment. [beat] JOSH: What should a builder take from the OpenRouter and Stripe move? ERIK: Stop treating AI calls like one-off scripts. Treat them like production dependencies. Track cost per task. Track failure modes. Store prompts with versions. Write evals. Put the calls behind an interface so you can switch models without rewriting the app. JOSH: That sounds less fun than prompting. ERIK: It is less cute. It also works. JOSH: And the market is moving that way? ERIK: Fast. Model marketplaces, payment rails, agents, coding tools like fx, requests for AGENTS.md support. The pattern is obvious. AI is becoming an execution layer. The winners will be the people who give that layer clean instructions, clean data, and clean boundaries. JOSH: And the losers? ERIK: They paste the AI into Slack and call it transformation. [pause] ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Put an AGENTS.md file at the root of your repo today. Keep it short. Tell the agent how to run tests, where the main app lives, what files it should not touch, how commits are named, and what counts as done. JOSH: That's it? ERIK: That's the start. Add the weird stuff too. If migrations require a local database, say that. If frontend tests need a dev server, say that. If Terraform plans are read-only unless approved, say that in plain English. JOSH: Why does that matter so much? ERIK: Because agents don't need motivation. They need constraints. A good AGENTS.md turns "go fix this" into a repeatable workflow. Mine is boring on purpose: inspect first, patch small, run the narrow test, then run the broader test if the blast radius is bigger. JOSH: What's one line people should add? ERIK: "Do not rewrite unrelated files." That single sentence will save you pain. That's your tip. Use it. [pause] JOSH: Track your freedom score and net worth with the Freedom Blueprint app — free download, link in the show notes. [pause] JOSH: One more thing — we started a Discord for builders. If you're shipping AI, automation, or anything that makes a human obsolete — come hang out. Link at buildorbereplaced.dev. ERIK: Post what you built. We'll post what we're building. Real wins, real builds, no fluff. [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.