DField SolutionsMérnöki stúdió · Budapest
Loading · Töltődik
Skip to content
Back to glossaryTERM

Soft delete vs hard delete

Related service Website & online shop

DEFINITION

Soft delete: the row stays in the table, only a deleted_at timestamp or is_deleted flag is set, and every query filters by it. Hard delete: DELETE FROM truly removes the row and the associated audit trail or backup is the only memory of the past. Soft delete is convenient: reversible, undo-able, easy to audit. On the GDPR side it is a trap. An erasure request under Article 17 (right to erasure) means a soft-deleted row that still holds personal data is not erased, and if your background jobs, analytics, ML feature store, or backups keep reading it, you have not honoured the request. Fix: two-stage deletion. A user-facing delete sets soft delete (30-day undo window), and a scheduled job after 30 days hard deletes the PII (or anonymises it and keeps the numeric columns for statistics).

RELATED TERMS06
  • SSR (Server-Side Rendering)→

    HTML rendered by the server per-request, fresh for every user. Ideal for dynamic content (dashboards), but slower than SSG.

  • SSG (Static Site Generation)→

    Pages are produced at build time as HTML and served from a CDN. Near-zero TTFB. DField's own site runs this way across 111+ pages.

  • ISR (Incremental Static Regeneration)→

    SSG + timed regeneration: the HTML is static but regenerates on a schedule. Ideal for blog content · freshness with CDN speed.

  • Edge rendering→

    Code runs at the CDN edge closest to the user (Cloudflare Workers, Vercel Edge). Dynamic responses with ~10–50 ms TTFB.

  • RSC (React Server Components)→

    React components that run exclusively on the server and never ship to the browser. Result: less client-side JS and faster hydration.

  • LCP (Largest Contentful Paint)→

    Time until the largest visible element paints. Google Core Web Vitals passes under 2.5s · we usually land marketing pages under 1s.

MENTIONED IN THE BLOG05