When building SQL queries it can be tempting to lean on shortcuts. There’s a certain convenience in writing SELECT * instead of listing every column you actually need. It feels fast, flexible, and harmless. This is especially true during development, when schemas change frequently and you just want to explore your data. But habits formed in development tend to follow us into production, and once they do, these “harmless” shortcuts can become liabilities.

The Hidden Cost of Being Implicit

The trouble with non-explicit queries is that they rely on the current shape of the data rather than the intended shape. Which is fine, until something changes. Maybe a column gets added, renamed, or removed. Maybe data comes from a different environment than the one you tested against. Or maybe the system you depend on behaves slightly differently in production. Whatever the trigger, too-general queries introduce ambiguity, and within ambiguity is where bugs hide.

A Real-World Failure: Cloudflare

A dramatic example of this played out recently when Cloudflare experienced its largest outage in six years. Their automated bot detection workflow depended on a SQL query that selected columns from a table without restricting the database or schema context that table belonged to. Because the query wasn’t explicit about where the table lived, it unexpectedly pulled in additional data from a newly created table of the same name in another database. Those extra columns cascaded into downstream systems, pushing internal constraints past their limits and ultimately caused widespread 5xx errors. What initially looked like a massive DDoS attack turned out to be the result of a missing condition in a SQL WHERE clause:

SELECT
  name,
  type
FROM system.columns
WHERE
  table = ‘http_requests_features’
ORDER BY name;

This query worked, until it didn’t. And importantly, nothing inside the query would have warned engineers that it was too general. That’s the real lesson here: problems caused by lack of explicitness rarely announce themselves upfront. They surface only when the system evolves, often at the worst possible time and at a scale disproportionate to the simplicity of the mistake.

The Case for Explicitness in Production

As developers, we can’t foresee every future schema change or integration nuance. But we can control how intentional we are in our production code. Explicitness, whether in SQL databases, API configurations, or data pipelines, provides guardrails that prevent subtle assumptions from turning into major outages. The cost of being specific, while seemingly tedious during development, is small. The cost of being vague is unpredictable. And unpredictability is the one thing production environments never tolerate well.