Open Buffer. Find the LinkedIn post you wrote last September. The one about your product launch.
Can't find it? That's the point.
Every social scheduling tool — Buffer, Hootsuite, Typefully, Postiz — stores your content in their database. Your posts are rows. Your drafts are rows. Your publishing history is rows. Rows you don't control, can't query directly, and can't take with you.
This isn't a minor inconvenience. It's an architectural choice with consequences.
The database problem isn't about databases
Databases are great. I use them every day. The problem isn't that these tools use PostgreSQL or MySQL. The problem is that your content is trapped inside someone else's database.
When your content is a database row:
- You can't grep it. Want to find every post where you mentioned "kubernetes"? Log in, scroll, use their search (if it exists).
- You can't version it. Edited a post before publishing? The original is gone. No diff. No history.
- You can't back it up. Maybe there's a CSV export buried in settings. Maybe.
- You can't move it. Switching from Buffer to Typefully? Start over.
When your content is a file:
- grep works.
grep -r "kubernetes" posts/— done. - git works. Every edit is a commit. Every version is recoverable.
- cp works. Back up your entire publishing history:
cp -r posts/ backup/ - You own it. No export needed. It's already on your machine.
Files are the most portable, durable, universal storage format humans have ever invented. Every operating system reads them. Every programming language reads them. Every text editor reads them. They'll outlive every SaaS tool on the market.
Markdown is the right file format
Not JSON. Not XML. Not YAML. Markdown.
Markdown is readable without any tool. Open a .md file in Notepad and you can read it. Open a .json export from Buffer and good luck.
More importantly, markdown already has a standard for metadata: frontmatter. YAML at the top of the file, content below. Every static site generator, every documentation tool, every developer notebook uses this convention.
---
platforms: [bluesky, mastodon, linkedin]
scheduledAt: "2026-04-01T09:00:00Z"
published:
bluesky: "https://bsky.app/profile/..."
mastodon: "https://mastodon.social/..."
---
Just shipped v2.0. Here's what changed and why.Everything about the post — where it was published, when, on which platforms, the permalink — lives in the file itself. The file is the record.
The filesystem is the original database
This isn't a new idea. It's the oldest idea in computing.
Unix got this right in 1969: everything is a file. Logs are files. Configuration is files. Mailboxes were files. The filesystem was the universal interface.
Then web apps came along and put everything in databases. For good reasons — concurrent access, transactions, indexing. But for personal content? For a solo creator publishing a few posts a week?
You don't need PostgreSQL. You need a folder.
A folder of markdown files gives you:
- Version history —
git log posts/launch.md - Full-text search —
grep -rl "product launch" posts/ - Backup — push to any git remote
- Sync — Dropbox, Syncthing, rsync, whatever you want
- Automation — cron jobs, shell scripts, CI/CD pipelines
No ORM. No migrations. No connection strings. No scaling concerns. A folder and a process.
What about collaboration? What about teams?
Git handles collaboration. Pull requests are content review. Branches are draft workflows. Merge conflicts are a sign that two people edited the same post — which is a real conflict that should be resolved, not silently overwritten.
This isn't theoretical. Every software team already works this way with code. Documentation lives in repos. Blog posts for developer-facing companies live in repos. Why should social posts be different?
The system of record argument
Here's the part most people miss.
When you publish a post to Bluesky, the platform gives you a permalink. That permalink is the canonical proof that you published that content at that time. It's valuable metadata.
But where does that permalink live? In Buffer's database. In Typefully's database. Not in your files.
A file-first publishing tool writes those permalinks back into your markdown. After publishing, your file looks like this:
---
platforms: [bluesky, mastodon]
published:
bluesky: "https://bsky.app/profile/you/post/abc123"
mastodon: "https://mastodon.social/@you/456789"
publishedAt: "2026-03-26T09:00:00Z"
---
Your post content here.Now your markdown file is the system of record. It knows what was published, where, and when. Your entire publishing history is a folder you can search, back up, and own forever.
No SaaS tool can take that away from you. Not even an acqui-hire.
This is what we built
Blurt is a social publishing tool where your posts are markdown files. Write a file, publish to 6 platforms, get permalinks written back into your frontmatter.
No database. No vendor lock-in. Open source, MIT licensed, self-hosted with a single process.
Because the best place for your content is a file you own.
Blurt is open source and building in public. Check it out on GitHub or follow along on Bluesky and Mastodon.