The default SaaS architecture diagram has six boxes around the database. I run one box, doing four jobs, for $25 a month.
How one database doing four jobs saved me from hiring three specialists.
In Part 3 I walked through the bill. One line that didn’t appear: managed Redis. Or Elasticsearch. Or a queue-as-a-service. Or a separate authentication provider.
That’s not because I don’t need any of those things. Both products need queues, search, auth, and the rest. The difference is that one database does all of them. That’s the business decision this piece is about.
The question that drives the stack
The default SaaS architecture diagram has one box for the database and roughly five other boxes around it — Redis for queues, Elasticsearch for search, Auth0 for users, a CDN for files, a separate analytics warehouse for reporting. Each is a sensible specialist choice. Each is also a separate bill, dashboard, failure mode — and eventually a separate person who knows how to operate it.
For a coffee-budget business with one engineer and two AI tools, that picture isn’t sustainable. Every additional service means $50-200 a month, an hour a week of attention, and a slow march toward the headcount I’m specifically trying to avoid.
So the question I asked was: how few separate services can I get away with, while still running a real product?
The answer turned out to be: one database, doing four jobs.
The four jobs Postgres does for me
1. The system of record. Customer accounts, subscriptions, backup results, audit logs. About 2 million rows across both products. Supabase Pro at $25 a month covers it — including auth, row-level security, and daily backups.
2. The job queue. pg-boss runs queues inside Postgres, in the same process as the web app. Fifteen job types — backup runs, schedule firings, email sends, schema scans. Zero extra services. The same database that holds the data also coordinates the work being done to it.
3. Background coordination. Advisory locks enforce single-leader execution when the web app scales horizontally. No Redis lock service, no Zookeeper. Just a column in a table.
4. Analytics and reporting. Customer dashboards, admin views, daily summary emails — all from named Postgres functions returning JSON. No data warehouse, no ETL pipeline. The reporting query runs on the same database the user’s row was written to thirty seconds ago.
Four services collapsed into one. Four bills into one. Four sets of operational knowledge into one.
Why Supabase, not raw Postgres
I have run databases. I know what that means — backups that actually restore, version upgrades that actually work, replicas that keep up, security patches that land before someone finds out you missed them. It’s real, specialist work. And it does not directly grow the business.
Supabase does all of that for $25 a month. In return I get standard Postgres — not a proprietary query layer, not a walled garden. The data is mine: any query, any export, any migration out, on demand. The deal is “pay them to run the boxes; the data stays mine.”
That’s the version of “managed” I’m willing to depend on. Not the kind where the vendor’s proprietary layer becomes the next platform I have to escape from.
What I deliberately didn’t bolt on
- No managed Redis. pg-boss replaces both the queue and the lock service.
- No Elasticsearch. Postgres full-text search handles every use case in both products. When it eventually doesn’t, I’ll revisit. Not before.
- No Auth0 / Clerk / WorkOS. Supabase Auth is already in the $25. Adding a second provider would be paying for the same problem twice.
- No separate analytics warehouse. Reports come straight from Postgres functions. No nightly export, no warehouse bill, no “the dashboard is wrong because the sync failed yesterday.”
- No NoSQL store for anything. When I’m tempted to “just use Mongo for this one thing,” I write a JSONB column instead.
Combined refusal: roughly $100-150 a month of services that would otherwise be on the bill — and, more importantly, a class of operational complexity that would be on my Tuesday afternoons.
The honest caveats
This isn’t a one-size-fits-all argument. Postgres-as-the-stack has real limits.
- At very high write volumes, pg-boss starts to compete with the application for database connections. But reach for SQS only when you actually need what SQS gives you — strict ordering, multi-service decoupling, very high throughput. If the queue exists just to decouple processing from the request cycle, SQS is more moving parts than the problem deserves.
- At very high search volumes, Postgres full-text starts to lose to Elasticsearch. I’m not there either.
- At multi-region scale, a single Postgres becomes a constraint. I run in one region on purpose.
The framing: use Postgres until it stops being enough, then add the next service. Not the other way around. Most teams reach for Redis on day one because the architecture diagram says they should. Mine doesn’t, because I can’t afford the headcount the architecture diagram quietly implies.
What this gets me, in business terms
- One mental model. Schema, queries, queues, locks, reports — all SQL. Claude and Codex are excellent at SQL. They are not equally excellent at the bespoke configuration languages of five other services.
- One bill. $25 a month for Supabase Pro covers what would otherwise be five line items.
- One thing to back up and monitor. Daily Supabase backups protect everything in one go. When the database is up, the stack is up.
When one of these jobs outgrows Postgres, I’ll break it out. Until then, every separate service I add is a salary I haven’t earned the right to spend.
The test I keep applying
Just because I can run something — and it sounds great on paper — is not a business reason for me to run it.
Every default architecture diagram has a service on it because it sounds smart, not because a customer needs it. Elasticsearch because “we’ll want better search someday.” Redis because “we’ll need a cache eventually.” A separate analytics warehouse because “real businesses have one.”
Each passes the technical justification test. None of them passes the business test: is a customer paying me more, or am I saving real time, because this service exists?
If the answer is no, it doesn’t belong on the bill.