They Needed a Database, Not a Database Administrator.

The orders started coming in faster than David Okello could keep track of by hand. Sokoni — the marketplace he'd built to connect smallholder farmers outside Kampala directly to city buyers — had gone from a demo he showed his co-founder to something forty real farmers were using to list their harvest, in about three weeks. The problem was where all of that actually lived: a folder of JSON files on the same server running the app, one crash away from disappearing.

He'd built Sokoni fast: a Next.js frontend, a small Express API behind it. Getting farmers listing produce mattered more than getting the data layer right on day one, so the API just read and wrote to flat files on disk. That was fine for a demo with five fake listings. It was not fine for forty real farmers' actual harvests and the buyers now placing real orders against them.

The trigger arrived on a Thursday: a buyer in Kampala placed an order for three sacks of matoke, and the confirmation never went out. The API had crashed mid-write, and the order went with it. There was no transaction to roll back to, because there was no database — just a file that had been open at the wrong moment.

David knew what came next in theory: a real database. PostgreSQL, specifically — familiar, reliable, exactly what Sokoni needed. What he didn't know was how to run one without becoming, in practice, the person responsible for keeping a database server alive: patching it, watching its disk, being the one people called if it fell over. Sokoni had two people. Neither of them was a database administrator, and neither wanted to become one just to store a harvest listing.

"He didn't need to learn how to run a database. He needed a database to already be running."

He added PostgreSQL to Sokoni's project from the Qeda dashboard — no server to provision, no installation, no configuration file to write by hand. A minute later he had connection details his Express API could use directly. He swapped the file reads and writes for real queries, deployed the change the same way he deployed everything else — a git push — and matoke orders started landing in a database instead of a folder.

Billing followed the same pattern as everything else Sokoni ran on Qeda: one wallet, topped up with Mobile Money, covering the app and the database together. No separate invoice from a database vendor, no new currency to reconcile at the end of the month.

With the core data problem solved, David started sketching a feature he'd been putting off — recommending buyers the closest available harvest by location and crop type. When he builds it, the plan is PostgreSQL with pgvector, provisioned the same way as the database he already has, sitting next to the data it would be searching instead of living in a separate system he'd have to stitch in.