Posts or Records: When Your Website Should Own Its Database

This post is part of Beyond the Hybrid, my guide to the web architecture ladder, from legacy CMS to sites that own their own database.

Every content management system makes one big assumption: that your business can be described as a collection of documents. Posts, pages, products, each with a title, a body and some custom fields. For a publisher, that assumption is a gift. For a lot of businesses, it is the quiet reason their website never quite does what they want.

Pages versus records

A page exists to be read. It has an author, a publish date and a URL, and it changes when someone edits it.

A record exists to be used. A verified business listing, a member with a plan, a booking with a time slot, a generated video clip with a quality score. Records have relationships, permissions and rules. They change because something happened: a payment cleared, a review was posted, a job finished.

You can store records in WordPress. People do it every day with custom post types and a stack of plugins. But every relationship becomes a meta field, every rule becomes a hook, and every new capability becomes another vendor’s roadmap you now depend on.

What it looks like when the site owns the data

Four of the sites I run have no WordPress at all, and the reason in each case was the shape of the data:

• Lakewood Ranch AI is a community directory. Its Firestore database holds businesses, reviews, events, classifieds, loyalty data and ad bookings, with serverless APIs in front of them.
• Florida Man AI looks like a publication, but underneath it is a 27-model Postgres schema tracking sources, claims, editorial review and generated media, fed by a job that runs every morning.
• OneFront is a product. Users, profiles, links and click analytics live in Neon Postgres, with Redis buffering the clicks so a viral spike does not hammer the database.
• ClipMaster takes in long videos and produces scored, captioned clips, storing projects and media references in Postgres beside the server that does the processing.

None of those started from the question “which CMS should we use?” They started from “what are the things in this business, and how do they relate?” The website came after the data model.

Five signs you have crossed the line

1. You have more custom post types than real pages.
2. Users need to log in to do something, not just to read something.
3. Important work happens on a schedule, not when someone clicks publish.
4. Your plugin list includes more than one “framework” plugin holding the others together.
5. You are exporting data from the website into another system to actually run the business.

Two or more of those and you are running an application inside a CMS. That can work for a long time. It just stops getting cheaper.

The honest counterweight

Owning the database means owning everything around it: backups, migrations, access control, the admin screens editors used to get for free. I wrote a full accounting in The Real Cost of Owning Your Stack. The decision is not “modern versus legacy”. It is whether your business is made of pages or of records.

Where to go from here

If you are trying to work out which rung your site belongs on, start with the full ladder, or see rebuild options and price ranges. If you would rather just ask, tell me what your site has to do and I will tell you what I would build.