Wrong ways to use the databases, when the pendulum swung too far

Author, Style, and “Joints” Joke

• Some readers were briefly confused about the author’s identity and the “joints”/Snoop Dogg gag; others took it as a weed joke that unfortunately undermines perceived SQL expertise.
• Overall, several readers still found the article valuable, especially as a counterweight to anti-SQL/anti-RDBMS fashion.

Checkpointing, Idempotency, and KV Stores

• A long subthread unpacks the “checkpoint” UUID system over a KV store: it was primarily for idempotency under uncertain write outcomes, not just concurrency control.
• Commenters compare it to optimistic locking using etags:
  • One side argues proper conditional writes and retries should avoid extra reads/writes.
  • The other side stresses the “two generals” problem: you often cannot be sure whether a write actually succeeded, so external idempotency keys/checkpoints still matter.
• Example scenarios (payments, Strava-like uploads) illustrate when missed or duplicated operations are unacceptable, justifying complex idempotency schemes.

RDBMS vs NoSQL, ORMs, and “Religious” Positions

• Multiple comments criticize “religious” stances: all-in on stored procedures, all-in on ORMs, or all-in on microservices/NoSQL.
• ORMs:
  • Critics see them as abstraction-on-abstraction that encourages bad queries and hides fundamentals.
  • Supporters say teams using “raw SQL” often reinvent ad‑hoc ORMs anyway, and modern ORMs can be efficient if used thoughtfully and bypassed for hotspots.
• Some argue many devs reach for ORMs/NoSQL simply because they don’t know basic persistence alternatives.

Stored Procedures: Power, Pain, and Testing

• Several note stored procedures are excellent for bulk, set‑based operations near the data, especially for validation and ingestion workloads.
• Problems arise when:
  • They embed lots of business logic, cursors, and per-row processing.
  • They live on a separate deployment/test track from application code, with weaker tooling and fewer tests, so teams become afraid to modify them.
• Others point out SPs can be treated as a database-level API, useful when many heterogeneous apps share a DB and when permissions are limited to SELECT/EXECUTE.
• There is discussion of unit-testing frameworks and containerized Postgres as ways to make SP testing more normal.

Performance and Business Impact

• One commenter doubts bad code harms company finances; others counter with examples of:
  • Higher infra spend (oversized VMs, massive Lambda fleets).
  • Downtime, timeouts, and UX so slow it quietly drives customers away.
  • Opportunity cost: slower ability to ship new features and seize business opportunities.
• Several note these costs are often hard to measure directly, which is why companies tolerate inefficient systems.

Rewrites vs Incremental Evolution

• Multiple experiences with full rewrites:
  • Some report they often fail or take so long that the original market opportunity is gone.
  • Others say rewrites, when tightly coupled to real customer value and early feedback, have yielded substantial improvements.
• A nuanced pattern emerges:
  • Rewriting code you originally wrote yourself (e.g., from “disposable” bash to Go) can be a deliberate, productive two-stage design process.
  • Rewriting large legacy systems you don’t fully understand is much riskier than evolutionary refactoring.

Architectural Pendulums and Conservatism

• Several comments use political or cultural analogies (governments, South Park theme park episode, Chesterton’s fence) to frame the “pendulum” between heavy RDBMS-centric systems and oversimplified KV/NoSQL architectures.
• The recurring lesson: tradition often encodes hard-won knowledge; radical simplification (e.g., “just KV everywhere”) tends to rediscover the same constraints with more pain.
• Some suggest the real optimization target is organizational understanding: a team deeply grasping the problem domain may justify a rewrite; otherwise, incrementalism and respect for existing design is safer.

Minor Technical Side Notes

• One commenter observes that modern RDBMS JSON APIs (Oracle, SQL Server) can mutate deeply nested values, implying that some described mega-document and checkpoint pain could be mitigated with newer relational features.