A File Cannot Remember Anything: Adding a Database Without Regretting It

Your page works. Someone types their name into your contact form, presses send, and… nothing happens, or it opens their email client, or it silently does nothing at all.

That is not a bug. A file cannot remember anything. Crossing from a page that displays to a page that stores is the biggest single step in this whole series, and it is where the most people stop.

Who actually crossed the line

Of the 27 sites I scored, 15 connected a real database and 12 stayed fully static. That split is close to even — but it is not evenly distributed across the grade range.

The gap between the top seven and the bottom seven was widest in technical functionality: 3.6×. In content it was only 1.7×. Put plainly: the model writes everyone’s words to a similar standard. It does not make everyone’s features work. Storing data is where people actually diverge.

The line you are crossing

	Static page	With a database
What visitors get	Identical bytes, every time	Whatever is in the store right now
Hosting	Free, effectively forever	Free tier, with quotas
Can break because	Almost nothing	Quota, config, rules, outage
You must manage	Files	An account, keys and access rules
Right choice when	Nothing needs remembering	Something does

A static page is not a lesser thing. If your site is a portfolio, a CV, a landing page or a piece of writing, it should stay static and you should feel no shame about it. Cross the line only when there is something to remember.

What to ask the agent for

The mistake is asking for “a database.” Ask for the feature, and be specific about the rules — because the rules are the part it will otherwise guess.

Add a comment board to this page.

Store: name, message, timestamp.
Anyone may read. Anyone may post.
Only the original poster may delete their own comment,
  using a password they set when posting.
If the backend is unavailable, fall back to local storage
  and tell the visitor that is what happened.

Use a free-tier hosted database. Put the configuration in one
clearly marked block at the top so I can swap in my own keys.

The last line matters more than it looks. Without it you get credentials scattered through the file and no idea which ones are yours to change.

Three things nobody warns beginners about

1. Your key will be visible. A browser-side database key is in the page source, and anyone can read it. This is normal and expected — but it means your security rules, not secrecy, are what protect the data. Ship with rules that assume a stranger has your key, because they do.
2. “Anyone may write” means anyone will. An open comment board on a public URL will get spam. Not maybe — eventually. Decide now whether you want moderation, a rate limit, or simply to take it down when it happens.
3. The password field is not a login. A per-post delete password stored as plain text is fine for a class project and unacceptable for anything real. Know which one you are building. And check what the browser does with that field — a text input followed by a password input is a shape browsers try to autofill with the visitor’s saved credentials.

Before you add one, ask this

• Does anything need to survive a page refresh? If no, stop here. You do not need this.
• Would an email be enough? A contact form that emails you needs no database and no account.
• Who is allowed to read what gets stored? Answer before you write a line, not after.
• What happens when the free quota runs out? Know whether your site degrades or dies.

Frequently asked questions

Which database should I use?

For a first dynamic feature, any of the mainstream hosted options with a free tier will do, and the agent will pick one if you do not. What matters far more is that you write the access rules yourself rather than accepting the defaults.

Is the free tier really free?

Free until a quota — reads, writes, storage. For a portfolio comment board you will not come close. For anything with traffic, read the limits before you launch, not after.

Can I add this later?

Yes, and you should. Ship the static version, get it online, then add storage when you actually have something to store.

What if it breaks?

Ask for the fallback in the brief — local storage plus an honest message, as in the prompt above. A dynamic feature that fails loudly is far better than one that swallows a visitor’s message in silence.

How do I add a database to a plain HTML website?

You do not add it to the file. You add a service the file talks to. The page stays static — the same HTML for every visitor — and a few lines of JavaScript read and write to a hosted database over the network. That is why “add a database to my HTML site” has no file-level answer: nothing in the HTML changes except a script tag and a configuration block. Ask for it in exactly those words, and give the permission rules at the same time.

Next

That is the last of the how-to. The final article in this series is the uncomfortable one: what separated the 81-point site from the 17-point site, when both had the same tools, the same deadline and the same amount of help.