Everything Mercury Local publishes, across every publication, lives in one database. Not one per site. One.
As of this week that is 1,627 published articles, 378 pages, 2,722 profiles of the people, places and public bodies (councils, boards, commissions) we cover, more than a thousand source documents, more than 240 meeting transcripts and more than four thousand images, across sixteen publications, in one place, with one set of rules about who can change what.
I want to explain why that is the decision underneath every other decision in this series.
What "one" buys you
On WordPress, each publication was an island. A person covered by both The Charlotte Mercury and Strolling Ballantyne existed twice, or not at all. A meeting transcript belonged to whichever site uploaded it. An image lived in the library of the site that used it first.
In one database, a person is one record. A city council member has one profile, and every article that names him, on any of our publications, links to it. A transcript of a Tuesday meeting is one record, and every story written from it points back to it. An image is one file with one permanent address. When we launch a new publication, it inherits all of this on day one: every person, every place, every document we have ever filed.
That is the difference between a group of websites and a newsroom. A newsroom has a morgue, a library, a contacts file, and everyone in the building can use them. Three WordPress blogs had three of nothing.
What the database knows that a blog does not
A blog knows it has posts. Our database knows which source documents and transcripts a story cites, which people and public bodies it names, which steps of the editorial pipeline it passed, and how many verified claims stand behind it, each with the sentence in the source that supports it. It knows which publication owns which category and refuses to let a Farmington story carry a Charlotte category. It knows that two people with nearly the same name are probably one person and asks before creating the second.
None of that is exotic. It is what a database does when someone decides what the things in it are and how they connect. On a rented CMS you get posts, pages, tags and a media library, and everything else is a plugin someone else wrote for someone else's problem.
The rules live with the data
The most important consequence is one most readers will never see. When a rule matters, we put it in the database, not in a document somebody is supposed to remember. A publication's time zone is a column, so a Central-time paper renders its dates correctly without anyone thinking about it. Every change to a beat file, a person's profile, or a piece of money is written to an audit table automatically, with who changed it and what it was before. A transcript cannot be marked processed until the work it requires has actually been done.
We have a phrase for this internally: prose does not fire. A rule written in a style guide gets skipped on the busy night. A rule written into the database cannot be skipped by anyone, including me. The previous piece in this series is about those rules. This one is about why they have a place to live.
What it runs on
Postgres, hosted by Supabase, with permission rules attached to every row of data so the public can read what is published and only the newsroom can write. That sentence is the whole technical description and it is the last time it will appear in this piece. The point is not the vendor. The point is that the data is in a standard, open database that we can export in its entirety this afternoon and run somewhere else next week. On the rented app builder we came from, the twenty posts were baked into the app's code rather than stored anywhere we could read them out. We could not even get them out without reading that code.
Owning your data is not a slogan. It is a table you can query.
This is No. 13 in We Built Our Own. Previous: The database says no. Next: Sixteen publications, one codebase.