Sorted newest first.
Most list endpoints include a total count by default. The cost of computing that count grows with the result set, the value to customers is usually small, and the visible-correctness expectation that it creates is hard to satisfy. The right default is no count.
Changing a column type in Postgres often forces a full table rewrite while holding an ACCESS EXCLUSIVE lock. Some type changes avoid the rewrite entirely, others can be staged across multiple migrations to keep production traffic flowing.
Webhook subscriptions degrade silently. The customer notices when something breaks in production weeks after the integration started failing. A computed health score on each subscription surfaces degradation early without requiring customer instrumentation.
Postgres compresses large column values transparently using a system called TOAST. Since Postgres 14 the default algorithm can be switched per column from the classic PGLZ to LZ4, and the choice changes both compression ratio and CPU cost in ways most teams never tune.
Webhook subscriptions accumulate over months and years until customers cannot remember what each one does. The fix is metadata fields that are cheap to add and disproportionately load-bearing for self-service: name, description, owner, contact, and a few others worth specifying upfront.
SQL NULL is not a value. It is the absence of a value, and the difference produces a class of bugs that survives code review, type checks, and unit tests because the SQL standard explicitly defines NULL to behave the way that hides them.
Every webhook product accepts a customer-supplied URL and makes HTTP requests to it from infrastructure the customer does not control. The default behavior is server-side request forgery as a product feature. Recipient allowlisting is the discipline that closes the gap.
Single-event-per-delivery is the right default for webhooks and most B2B SaaS providers ship nothing else. There are specific scenarios where batching produces large operational wins, and the boundaries between when batching helps and when it hurts are worth being explicit about.
Silent data corruption is one of the rare failure modes that punishes good operational hygiene. Regular backups happily encode the corruption, replication propagates it to standbys, and the team discovers the problem when a restore reveals data that was already wrong months ago.
Postgres exposes a family of reset functions for the cumulative statistics views, and using them carelessly destroys the historical context that makes the views useful. The discipline of when to reset and what to capture first is one of the smaller operational habits that compounds over years.
Most webhook APIs let customers subscribe by event type and then ship every event matching the type. For high-volume integrations this is wasteful on both sides. Server-side filtering lets customers narrow further without writing infrastructure to discard most of what they receive.
Rate limits have two implementations that look identical in the documentation and behave very differently in practice. The fixed-window reset is cheap to implement and produces customer-visible cliff edges; the sliding-window reset is more expensive and produces smoother experience.