When building a product, there comes a point where you start debating whether to add a draft save feature. For services that deal with content -- blogs, social media, CMS tools -- it's practically considered essential. I went through the same dilemma, and this post is based on a conversation I had with a developer at the time.

What Is Draft Saving?

Draft saving is a feature that lets users save their writing even when it's not finished. You could have just a title, or only part of the body written, and it still saves. The key point is that it needs to save even when required fields are empty (NULL).

If you apply strict validation to draft saves, the NULL problem goes away -- but then it stops being a "draft." Users would have to complete their post before they can save anything.

Basic Structure vs. Draft Save Structure

The draft save feature looks useful from a user convenience standpoint, but it introduces significant complexity on the development and operations side. Comparing a basic CRUD structure with one that includes draft saving makes the difference pretty clear.

How Do You Store Draft Data?

When implementing draft saving, there are two main options.

1. Same table with a status column
   • Distinguish between draft and confirmed using a status value in a single table
   • The table structure stays simple, but records with lots of NULL values get mixed in
2. Separate table
   • Create a dedicated table just for drafts
   • Data needs to be moved to another table when confirmed

Problems with Draft Saving

1. Storage and Processing Issues with Draft Data

Draft creation and draft updates skip validation, so they process quickly. But problems arise when you try to finalize (confirm) that draft data.

1. The existing update process requires roughly double the source code
2. Additional logic is mandatory to re-run all validations when confirming draft data

2. Reduced Search Efficiency

To optimize search performance, NULL values in searchable columns need to be minimized. As data grows, search speed on tables with lots of NULL values degrades exponentially.

Draft data is likely to have NULL values in most required fields. This breaks database normalization and causes search performance to worsen on an upward curve as data increases.

If you store drafts in the same table, you avoid the extra complications of table splitting. But you'll need to build completely separate pages in the admin panel for confirmed posts and drafts, which increases development costs.

To Sum Up

There are two main reasons to minimize the draft save feature.

1. Database normalization and performance issues

   Structural inefficiency and degraded search performance caused by excessive NULL values

2. Increased development complexity

   More time spent on additional APIs and validation logic needed for the draft-to-confirmed transition

So What Should You Do Instead?

If you absolutely have to implement draft saving, at least consider these approaches.

1. Use local storage first

   Store draft data in the browser instead of sending it to the server. This significantly reduces development complexity, but cross-device sync isn't possible.

2. Set an expiration period

   Automatically delete draft data older than 7 days to reduce the load on your database.

But the most important thing is to decide whether draft saving is actually a necessary feature in the first place. A single feature that looks simple on the surface can have a much bigger impact on your entire system than you'd expect. The decision not to add a feature is just as important as the decision to add one.