Why we do not add a database to a marketing website by default

A database is not a badge of seriousness. It is a system that creates obligations. Once a website stores its own application data, somebody has to decide what gets stored, how it is validated, how long it remains, who can access it, how backups work, how migrations work, what happens during an incident, and how the data is exported when the client leaves.

If the site does not need that capability, those obligations are self-inflicted.

Marketing sites and applications are different things

A lead-generation website usually needs to publish information and move a visitor toward a call, email, form submission, booking, or another controlled action. An application may need accounts, saved state, permissions, transactions, user-generated records, workflow state, or data that changes independently of a deployment.

Those are different jobs. We build both kinds of systems, but we do not pretend a six-page contractor site becomes more capable because it has a database behind the contact page.

What we do instead

On several production sites, the public website owns the user interface and validation while a specialized provider owns the durable form record. On one build, for example, a gated resource uses a small server route. The browser sends an email address and an explicit consent value to that route. The route validates the shape of the request, rejects incomplete submissions, forwards the approved fields to the form provider, and returns a success response. A short-lived access cookie controls the download experience.

There is no local customer database because the feature does not need one. That is a meaningful architectural decision. The website still has server-side control over what it accepts, but it does not create a second system of record merely to duplicate data that already belongs in a form or CRM workflow.

Fewer stored records means fewer breach questions

Every piece of data you choose to persist becomes something you have to protect. Names and email addresses are not as sensitive as payment credentials or health data, but they are still data about people. The safest unnecessary database is the one you never created.

Avoiding storage does not eliminate security responsibilities. The form still needs validation, transport security, abuse controls, sensible logging, and a trustworthy downstream provider. It does reduce the number of places the information can leak from.

It also makes handoff simpler

A site with no private application database is unusually easy to transfer. The repository can move. The domain can move. The deployment can move. The form destination can be replaced. There is no hidden production dataset that has to be dumped, transformed, re-imported, and reconciled before the new owner can run the site.

That matters to us because client ownership is part of the architecture.

When a database becomes the right answer

We add persistent storage when the product needs persistent state. Examples include:

• user accounts and permissions
• saved business records
• application workflows
• inventory or order state
• internal dashboards with durable data
• user-generated content
• synchronization jobs
• transactional records that the application itself owns

At that point, the database is not decorative. It is part of the product. The design conversation changes too. We have to discuss data models, migrations, authorization, retention, backups, observability, and failure recovery.

The middle ground matters

Sometimes a website needs a little server-side behavior without needing a database. Route handlers can validate requests, proxy to a provider, create a signed response, verify a webhook, or gate access to a resource. That gives us controlled server logic without turning every interaction into a persistence problem.

This is one reason we like the server capabilities in Next.js. We can add a narrow server boundary when the feature needs one instead of reaching immediately for a separate backend stack.

Why the decision improves performance

A static or mostly static site can often be generated ahead of time and served with very little request-time work. A database-backed page introduces a dependency that must be queried or cached. Again, that can be correct for an application. It is simply waste if the page contains content that could have been built yesterday and served instantly today.

Why the decision improves reliability

Every network dependency is another thing that can fail. If the database is unavailable, a database-dependent page may fail. If the marketing page was generated from repository content, the deployed page keeps existing even if every internal development tool is offline. That is a valuable property for a public site whose primary job is to remain available.

Our rule is simple: data infrastructure should answer a data problem. We do not create the problem in order to justify the infrastructure.