Second Brain for Business: Why I Put Everything in One Database

A second brain for business is a database you own, not a note app

Let’s get one thing straight. A second brain for business is a database you own, not a note app. Mine is one Postgres database. Every client, quote, invoice, booking and article of ours sits in one database we own (KhaordicOS on Postgres). That is what lets an agent read the whole business through one door, and it is the only version of this idea I would bet a company on.

The phrase belongs to the note-taking world, and fair enough. Tiago Forte taught the Building a Second Brain method to 6,000 students over six years, then stopped the cohorts in early 2023, a couple of months after ChatGPT came out, because, in Forte’s words, the impact of the new technology was already clear. I respect that call. But Forte’s second brain holds what you know. A business also has to hold what it sold, to whom, what is still owed and when the next appointment is. A note can describe an invoice. It cannot be the invoice.

Most of what ranks for this phrase describes a second brain for notes, or for an AI pipeline. What follows is different: one operator’s dated move of the clients, quotes, invoices and bookings into one database, with what it cost.

The people who run a business on it end up in the same place. Iwo Szapar runs a business on a system whose foundation is a Supabase PostgreSQL database, not a folder of notes. Same instinct. Tables, not pages.

Here is what mine holds, counted on 2026-10-14 (tables, not rows):

Schema	Tables	What lives there
cms	483	The CMS for every site, plus Business (clients, quotes, invoices, time) and, since 2026-08-18, the one users table
osi	47	The content engine: articles, clusters, files
agents	11	The agents service
bookings	6	The booking service

Four schemas, one database. A schema is a named section of the database, so each service keeps its own tables while everything stays one query away.

One disclosure, said once: Claude Code wrote this column at the draft hold of my editorial pipeline, and the pipeline checked it, fact-checked it against my records and graded it.

Why most second brains die: habits, not tools

If you have ever watched a business abandon its note system, you already know this one. Management Consulted’s guide notes it plainly: “The most common reason second brain systems fail is abandoned habits, not bad tools.” Correct. Annoyingly correct. Most note systems sold to a business assume someone will file things, tag things and review things every week, forever.

Iwo Szapar’s version of the rule is better: “if it requires me to remember, it will fail.” Szapar’s case study describes a whole system built around that sentence, and I’d put it on the wall of every small business that has ever bought a CRM and then abandoned it.

So the fix cannot be a better habit. The fix is plumbing. In a business database, the record exists because the work happened, not because somebody remembered to write it down later. A quote written in Business is already a row in the database. A booking made on the booking page is already a row in its own schema. Nobody files anything. The filing is the work itself.

That is the step the popular advice skips. Notes are where you think. Records are where you get paid. Mixing them up is how a business ends up with its client list in one app, its quotes in another and its bookings in a third, and a person in the middle copying between them by hand.

Knowledge vs records: why markdown is not enough for invoices

Ryan Doser’s playbook describes a second brain built from plain markdown files, and its best line is right: “The models are rented. The knowledge is owned.”

Markdown is great for what I know. It is a rough place to keep the invoice that is 30 days late, because a text file cannot tell you which invoices are 30 days late. A query can. That difference is the whole argument.

A post on r/ModernOperators notes the line in one sentence: “A second brain remembers what YOU know. A company brain runs how your COMPANY operates.” The note app is the first half. The database is the second half, and the second half is the one that sends the reminder, books the call and knows who has paid.

	A note app	A business database
Holds	What you know: ideas, drafts, research	What happened: clients, quotes, invoices, bookings, articles
Answers	“What did I think about this?”	“Who owes us, and since when?”
Gets filled by	You, when you remember	The work itself, as it happens
An agent can	Read your notes	Read the records and act on them through a checked door

None of this makes notes useless. It makes them a different tool. A note app is a library. A business database is a ledger, a calendar and a client list that agree with each other because they are the same thing underneath.

If your current “second brain” cannot answer the second row of that table without you opening four tabs, it is a notebook with good branding. Keep it for thinking. Then put the records somewhere that can answer questions on its own.

The path: WordPress, then Hygraph, then Payload, then one database

I didn’t start here. In my own words: “At the very beginning I started out on WordPress. I quickly got very frustrated with the user experience: slow, outdated, PHP-focused. You try to customize anything, you’re charged for it, and the plugin system sucks. Most of them don’t work, and those that do charge for the working version of it.”

So I moved to a headless CMS, since I could code before ChatGPT 3.5 came out and everything changed. I used Hygraph (its documentation), because it was performant, and GraphQL worked very well with my, frankly, crazy complex content systems. Then Payload came out (its documentation): TypeScript native, made to work with React and Next.js. A match made in heaven for me. Payload was the first tool that let me, as a single person, manage content at scale. Anything I built to fix a productivity, complexity or customization problem came with its backend and its database already shaped.

I’ve used most tools on the market, and built my own because of them. But building my own created the next mess. Each app kept its own database and its own login tables. A client, a quote, an article and a booking lived in four different places, and nothing could read across them except me, by hand.

The decision was one Neon project (Neon is hosted Postgres, and its documentation covers the branching I used) with one schema per service. My written reason at the time: it was the cheapest change that opened the most doors, because agents could read across services with plain SQL and logins would get one home. I rehearsed it on a Neon branch, a throwaway copy of the database, then moved each app’s data one schema at a time with pg_dump, a PostgreSQL tool for extracting a database into a file. The cutover ran on 2026-08-06. The old databases were removed only after a week of clean operation.

In my words again: “So I merged everything into one database, because it finally became cost-efficient and doable for me, while keeping maximum flexibility, modularity, scalability and resilience.” The CMS that reads this database later outgrew Vercel’s Hobby plan, as that fix documents, which is its own story.

1. 01WordPressSlow, outdated, PHP-focused; plugins charged for
2. 02HygraphHeadless CMS, performant, GraphQL
3. 03PayloadTypeScript native, built for React and Next.js
4. 04One databaseOne Neon Postgres, a schema per service

The dated record: users merged, agents arrived, one door

Dates, because “we centralized our data” means nothing without them.

Date	What happened
2026-08-04	The booking service joined, with its own schema
2026-08-06	The cutover: the data moved into one Postgres
2026-08-17	One storage bucket per app for files
2026-08-18	Logins moved into one users table owned by the CMS; 128 users merged
2026-08-19	The agents service arrived, with its own schema
2026-10-08	Every article goes through the editorial pipeline over the machine door

The 2026-08-18 line is the one I’d frame. Before it, logins lived in two tables, and the split had silently broken every write whose author pointed at the copy of a user instead of the user. Merging the 128 users into one table owned by the CMS fixed a bug that had made no noise at all, which is the most humbling kind.

Then the door. My content engine has a machine door: an API key, checked on every request. Since 2026-10-08, every article goes through the editorial pipeline over that door, this one included. To be precise, because people stretch this claim: agents do not get a raw SQL login to everything. They get one checked door into the content engine, and the engine reads what it needs. That setup gets its own column, which documents how to give an agent your business context through one door.

Two smaller things the shared database made boring, in a good way. My console reads Business and the bookings to draw its dashboard and calendar, with no export step between them. And the site chat and the pipeline’s internal links read one site index, rebuilt every night at 05:30 UTC.

If you want the business-owner version of this argument, minus my war stories, clevrstart has a guide on how to centralize your business data without building it all yourself.

1. 01Booking joins2026-08-04, with its own schema
2. 02Cutover2026-08-06, data moved into one Postgres
3. 03Users merged2026-08-18, 128 users in one table
4. 04Agents arrive2026-08-19, with its own schema
5. 05Machine door2026-10-08, every article over the API key

What it bought and what it cost

I’m not going to sell this as free. Here is the honest ledger.

It bought	It cost
Agents reach the business through one checked door	Test runs shared the real database
Cross-service reads in plain SQL	A demo login would have shown real clients
One home for logins, 128 users merged	The two-table split broke writes until the merge
A console that reads Business and bookings directly	Files still live outside the database

The first cost on record: on 2026-08-25, two parallel build runs had no file in common, but one run’s migration (a change to the database structure) broke the other run’s passing tests, because both used the same database. Since 2026-10-06, each build run gets its own empty database. That is the record. I am not calling it proven forever.

The second cost was worse. Business is one shared workspace, so a demo login would have shown real clients. The public demo got its own deployment and its own separate database on 2026-09-25 and 2026-09-26. Files never moved in at all: one storage bucket per app since 2026-08-17. And two things stay out on purpose. struxal, a separate product with paying customers, keeps its own database, because two trust domains must stay separate. flowingkhaos reader accounts live in the site’s own small API and database.

Meta’s engineers describe an organizational second brain as “a structured, auditable knowledge architecture” that keeps what the agent knows apart from how it reasons. Meta built that for specialists. I built the boring version for a company of one, and boring has rules of its own: the aftermath of the Vercel fix notes the one it left behind, “Always-on servers in a container, for a fixed floor.”

Now the limit, said plainly: I have measured no time saved, no money saved and no client result. What I am trying to prove is a goal, not a result: thousands of dollars a month in cash collected, on less than $500 a month in external services, ads aside. I state revenue only for a month Business shows it. And none of this means you will earn the same.

The ownership test, and what to do with it

My test for “own” is one question: can you export everything you put in, in a format something else can read, without asking anyone? If I can’t hand it to another tool without asking, I don’t own it.

Owning is not the same as running the server, so let’s be precise. My database runs on Neon, a paid service, and the rest of the stack runs on paid hosts too: Vercel, Railway, Trigger.dev and Cloudflare, plus paid model APIs. What I own is the data and the account, and I can move both. In my words: “I no longer need SaaS tools to conduct business. I connect to APIs, bring the data home and assemble what I need, with the database in sync and the backend ready, at all times.” The SaaS tools I dropped are the business apps, the CRM and invoicing and booking tools a business rents. Not the hosting.

There is a real risk on the other side too. Brian Madden at Citrix points to the second brain that lives as “a folder of plain text files on my laptop” and argues that it breaks how companies secure knowledge work. A database you own fixes the ownership half of that problem. You still have to run it like a business system, with real logins and backups.

Here is the test to run on your own stack today. Tick a box only when the export passes:

• Clients: export every client with contact details and history, then open the file in a different tool.
• Quotes: export every quote with its line items, not only the totals.
• Invoices: export every invoice with its payments attached.
• Bookings: export every booking with the client it belongs to.

Each box you cannot tick is an app you rent rather than own. The count of empty boxes is your rent.

One line, worked through, so you know what an answer looks like. Invoices: a rented invoicing app. Export: a CSV of the invoices, without the payment history. That line fails, because the payments stay behind. A passing line reads: Invoices: a table in our own database. Export: every row, with its payments, in one query.

If you would rather practise on a small project, the Travole workshop details every step, and it ends with your own copy deployed, with your own database, and you as its only admin. Its fifth step provisions Neon, R2 and Better Auth, as the step’s page details.

Is one database less exciting than a shiny note app? Yes. Will it still know who owes you money next year? Also yes.

Sources

• ADHD Second Brain: How I Run My Business With AI…
• What Is a Second Brain? How To Build One and Think Better
• How to Build and Sell an AI Second Brain (Full Playbook)
• Workers’ “second brains” break every assumption about how we secure knowledge work
• Introducing The AI Second Brain - Forte Labs
• An Organizational Second Brain: Building an AI That Learns From Experts - Engineering at Meta
• How To Build A Company Brain With Notion + Claude …
• How to centralize your business data
• Give an agent your business context through one door
• What Travole is, what it is for, who it is for — Deploy your own Travole
• Aftermath — Vercel Hobby could not carry the CMS
• Context — Vercel Hobby could not carry the CMS
• Provision Neon, R2 and Better Auth — Deploy your own Travole