Cloud or offline: where a restaurant POS should run
A cloud POS stops taking orders when the internet does. An offline one lives on a single PC. I have shipped both, and this is how I choose.
The first question a restaurant owner asks about a POS is the price. The second should be: what happens when the internet goes down at eight on a Friday night?
I have delivered the same restaurant POS in two forms. One runs in the cloud. One runs entirely on a PC at the counter. Neither is better. They fail in different ways, and the choice should follow which failure the restaurant can live with.
The cloud version
The app and its database are hosted together. Every till, the kitchen display and the owner's phone talk to one database.
What you get:
- One source of truth. There is nothing to synchronise, so there are no conflicts and no "which till has the right stock count".
- The owner sees sales from anywhere, live.
- Updates reach every screen at once. No visit to the shop to install anything.
- Backups are the host's routine, not a USB stick someone forgets.
What you give up is stated at the top of the deployment document, in bold: no internet means no POS. No taking orders, no kitchen slips, no closing bills. There is no local fallback to drop down to.
That is a deliberate trade. An earlier build did have an offline path. I removed it, because a system that can run from two databases needs rules for which one wins when they disagree, and every one of those rules is a way to lose a sale or count it twice.
The offline version
The same application, packaged to run on one Windows PC. The database engine runs on that machine. The folder has five files a cashier can understand: install, start, stop, check, reset password.
What you get:
- It works with no connection at all. Orders, slips, closing, reports.
- It is fast, because nothing leaves the building.
- No monthly hosting bill.
What you give up:
- Everything lives on one PC. If the disk dies and nobody copied the backup, the history is gone. A scheduled copy to a USB drive or a cloud folder is not optional.
- The owner cannot check sales from home without extra setup.
- Each update is a visit or a remote session.
- The PC has to be healthy. One install failed because the computer was missing a Microsoft runtime component the database needs. The fix was to ship that component inside the POS folder and add a check script that tests every requirement and prints OK or the problem. Now the check runs before the install.
How I choose
| Question | Points to |
|---|---|
| Is the connection reliable during service hours? | Cloud if yes |
| More than one till, or a kitchen display on another screen? | Cloud is simpler |
| More than one branch? | Cloud |
| Does the owner want to watch sales remotely? | Cloud |
| Frequent outages, or a location with poor coverage? | Offline |
| One counter, one PC, a tight monthly budget? | Offline |
A restaurant with a second connection as a backup, even a phone hotspot, removes most of the risk of the cloud version for very little money. I recommend that before recommending the offline build, because the cloud version is easier to keep correct.
Two technical notes for whoever hosts the cloud version
Connection pools. Behind a transaction pooler, the database client must be told to use a single connection per instance. Otherwise it stacks its own pool on top of the pooler and runs out of connections under load. That fails in the middle of a rush, not at deploy time, which is the worst moment to learn it.
Secrets. The app refuses to start in production if its signing secrets are shorter than 32 characters. A POS handles cash. It should not boot with a weak key because someone was in a hurry.
The short version
Ask what failure you can afford. If the answer is "we cannot stop taking orders, ever", run it on the counter and take backups seriously. If the answer is "we cannot have two versions of the truth", run it in the cloud and buy a backup connection.
The system itself is described in the Restaurant POS case study. The service page is POS systems for restaurants and retail.