EXPLAIN ANALYZE

TL;DR An open transaction on a read replica holds a read view, and a read view stops InnoDB from purging old row versions anywhere on that server.

TL;DR When df and du disagree by more than a rounding error, the missing space is in files that have been deleted but are still open, and the kernel will name the process holding them.

TL;DR An index-only scan reads the index and never touches the table.

TL;DR An EXPLAIN ANALYZE tree has one line that owns the time; find it before reading anything else, then diagnose two things separately: whether the query computes more than the question needs, and whether the filter matches an index’s leading columns.

TL;DR A data-technology migration is five migrations stacked on top of each other: the query surface, the coupling around it, the data itself, the operational model, and the long tail.

TL;DR The 2025 DORA report found AI raises delivery throughput and hurts delivery stability at the same time, and its AI Capabilities Model names seven things that decide which way that goes for a team.

TL;DR A MySQL schema that lived through the 5.7-to-8.0 upgrade carries two eras of collation: old VARCHAR columns on utf8mb4_general_ci, newer ones on utf8mb4_0900_ai_ci.

TL;DR A join across two schemas on the same MySQL server costs nothing to write, which is exactly why nobody counts it.

TL;DR If you run Consul, or any mesh with real health checks, you already own the primitives for narrow database self-healing: a check on a pressure signal, a watch that fires a handler, a handler that runs one vetted remediation and files evidence.

TL;DR Backups, replicas, and point-in-time recovery are all built for loss: a failure you notice roughly when it happens.

TL;DR Staying sharp in the LLM era isn’t nostalgia and it isn’t prompt-craft.

TL;DR Most production fixes patch the occurrence in front of you (reboot this box, clean these rows, bump this instance), which clears today and leaves the class of problem intact to recur.

TL;DR The catastrophic AI failure (the agent that DROPs a table) is the recoverable one: loud, attributable, and on a gated pipeline it mostly can’t happen anyway.

TL;DR The agents that hallucinate least are the ones calling narrow, opinionated tools and given the smallest possible job.

TL;DR Two alarms ride the same dashboard tile: the disk filling up, and the disk slowing down.

TL;DR A database alerting on memory pressure is almost never a workload that needs more RAM.

TL;DR A relational database pinned at 100% CPU is almost never running one expensive query.

TL;DR The judgment that lets an engineer override a model is built in the slow work the model now offers to do for them.

TL;DR Database troubleshooting is a learnable skill with a repeatable sequence: observe what’s happening now, categorize the wait, narrow to the specific cause, then act.

TL;DR Infrastructure alerts on a relational database almost always trace to query and schema choices, not capacity.

TL;DR MCP is a wire protocol; what sits behind it decides the blast radius.

TL;DR Pulling six months of evidence from Jira, GitHub, Slack, and 1:1 notes is mechanical work an agent can do in an hour.

TL;DR AI coding agents do hit 10x or better on a specific slice of work: greenfield internal tools where the agent authors the code and the conventions it later re-reads.

TL;DR Adding RAG to your existing Postgres usually 5x’s the storage on the affected tables, drives the HNSW index off a memory cliff that doesn’t degrade gracefully, and pollutes the buffer cache hard enough that unrelated OLTP queries regress at p95.

TL;DR Autonomous agents are the wrong abstraction for alert triage.

TL;DR A prompt instruction biases the next-token distribution.

TL;DR AI can propose and ship index changes against a database where the SME has built two things: a context system (comments on indexes, recorded history, workload evidence surfaced into the prompt) and a guardrails layer (performance regression tests, c…

TL;DR Frontier LLMs corrupt at least 25% of delegated multi-step document work in lab conditions.

TL;DR For teams whose week is shaped by inbound work, the sprint should hold only what is being worked on now plus what gets pulled next.

TL;DR Forward estimation breaks for any team whose week is shaped by work that arrives.

TL;DR For teams whose week is operational by nature (SRE, DevOps, platform, database and storage reliability, anyone whose sprint work coexists with a steady stream of alerts and partner-team asks), a weekly responder rotation breaks silos only when the o…

TL;DR Partition by the primary key, not by created_at, and let a background service manage boundaries based on observed growth.

TL;DR Teams ship more when each IC declares one focused goal in writing every morning and the team holds a brief sync at roughly 3pm to surface what isn’t going to plan and offer help on it.

TL;DR What most teams call “database tests” are application tests with a database underneath.

TL;DR A team’s output and motivation come from designing the work as a process: each person in a role that uses them well, an owned outcome attached to it, a cadence chosen deliberately.

TL;DR AI removed the implicit human review that used to catch database bugs.

TL;DR LLMs generate SQL from the catalog (column names, types, whatever constraints have been declared), and the silent-failure rate is set by the gap between what the schema describes and what the database actually contains.

TL;DR A CTO declares “full agentic” off a vendor demo.

TL;DR Cloud bills creep up because nobody owns bringing them down.

TL;DR A TEXT or JSON column moves the schema out of the database catalog and into application code; the data inside has a shape, but the DDL won’t tell you what it is.

TL;DR A schema describes the shape the database enforces; the data inside follows a second set of conventions (soft-delete coverage, sentinel values, encoding quirks, format drift) that live nowhere the catalog can show.

TL;DR UUIDv4 primary keys are globally unique and coordination-free, and the cost is paid every time you write a row: random B-tree positions, page splits, secondary indexes bloated with 16- or 36-byte key copies, and a working set that stops fitting in t…

TL;DR A wide table looks cheap because every column was added for a real reason; the expensive part is that rows grow, every write amplifies, and every secondary index inherits the bloat.

TL;DR A legacy schema looks like a design and reads like a sediment: layers of decisions from different eras, where names that once described the data no longer do and conventions that look uniform aren’t.

TL;DR A predicate is SARGable (Search ARGument able) if the database can use an index to evaluate it.

TL;DR A bare id primary key on every table makes a.id = b.id valid SQL between any two tables, which means neither a human reviewing the query nor an LLM generating one can tell which of those equalities are meaningful.

TL;DR A polymorphic reference is resource_id plus resource_type where the type string chooses which table the ID points to.

TL;DR An ORM is a coupling between schema shape and code shape, not an abstraction over it.

TL;DR Schema conventions only survive when automation enforces them.

TL;DR Keep the database narrow: NOT NULL, UNIQUE, FK within a service, simple CHECK for per-row invariants, generated columns for stable derived values.