When does your app need a separate backend?
A page that lists a bike shop’s hours can get by with text and pictures. A page that takes bookings needs somewhere to keep them so the shop and its customers can find them tomorrow. Start with the smallest task your app needs to remember. If your builder already saves those records and lets you control who can see them, you may be able to use what’s there.
What does your app builder already give you?
Follow one booking from the form to the shop’s list of appointments. Open the builder’s settings and find where that booking is saved. If the app has accounts or uploads, find those settings too.
Suppose customers can make appointments but only staff should see the whole schedule. Check whether the built-in service lets you give them different access. Bring in another service when you can name the job your current setup can’t do, such as keeping an upload private or letting you take a copy of the records.
Where do the booking, the customer and the photo go?
The backend is the part of the app that works behind the screens. It saves a booking, checks who is asking for it and decides what to send back. Several services can do that work together.
Supabase and Neon use PostgreSQL, often called Postgres, which organizes records in tables. SQL is the language you can use to ask those tables for information, such as all appointments on Saturday. Firebase’s Firestore stores each appointment as a document, a record with named fields, and groups those documents into a collection. If you already have an app, check which format it expects before moving the connection.
| Part | What it holds or does |
|---|---|
| Database | Keeps the appointment time, bike type and account that made the booking. |
| Sign-in | Identifies the customer so the app can check which bookings they may open. |
| File storage | Holds the actual bike photo. The booking can store a reference to that photo. |
Compare tools
Scroll the table sideways to read every column.
| Tool | What it providesRecords, sign-in and uploaded files. | Who runs itWho keeps the service available and applies updates. | How you restrict accessWhere to set the rules that protect a customer’s information. | What you can restoreWhich information the documented recovery method covers. |
|---|---|---|---|---|
| Supabase | A Postgres database, sign-in and file storage. | Supabase runs the hosted service. You can also arrange and maintain your own installation. | Set rules for each customer’s database records and for their uploaded files. | Database backups cover records. Keep a separate recovery copy of the actual uploads. |
| PocketBase | A built-in SQLite database, sign-in, uploads and an administrator dashboard. | You run and update the program on a computer you arrange. | Set collection rules for records. Mark sensitive uploads protected and check the file rule. | A built-in backup includes uploads on that computer. Files kept with another storage service need a separate copy. |
| Neon | A hosted Postgres database with optional sign-in and file storage. Check availability where you plan to run it. | Neon runs the database. You choose which additional services to connect. | If the browser uses Neon’s Data API to request records, set table access and per-record rules. Configure file access separately. | The database timeline covers records and managed sign-in data within its history window. Check file recovery separately. |
| Firebase | Separate services for records, sign-in and uploads. Cloud Storage requires a billing account. | Google runs the services. You choose and configure the parts your app uses. | Set Firestore rules for records and Cloud Storage rules for files. | A scheduled Firestore backup restores records into a new database. Plan account and file recovery separately. |
| Convex | A database that keeps documents in tables, code that handles app requests and file storage. Connect a supported sign-in service or use the Convex Auth library, which is in beta. | Convex can run the service. Its self-hosting option requires a server and maintenance you arrange. | Check record access in app-facing backend code. Anyone with a direct file link can reuse it. For private downloads, use code that checks permission on each request. | A backup covers records and can include files. Keep the app code, settings and pending scheduled work separate. |
| Xano | Postgres tables, a visual editor for backend actions, account features and file storage. | Xano runs hosted plans. Custom plans offer deployment in infrastructure you control. | Match the signed-in person to permitted records. For private files on Pro, check access before issuing a link. Anyone with the link can open the file until it expires. | Paid plans provide instance backups. Choose whether a manual backup includes uploads and confirm the retention on the actual plan. |
Can a customer save a booking and come back to it?
Confirm your test copy writes to test records, then use made-up information. A successful test shows that the booking is still there when its owner returns and stays private from other customers.
- Keep the two sign-ins separateSign in with two ordinary test accounts in separate browser profiles. Make a booking under the first account using a name you’ll recognize. Close the page, reopen the booking from that same account’s list and confirm the saved time before switching accounts.
- Try the first booking as the second customerOpen the first booking’s page address using the second sign-in. It should reveal no private details. If your builder can check the request that changes a booking, try it as the second account too. Go back to the first account and confirm that the saved time is unchanged.
- Confirm the second customer can still bookMake a separate booking as the second customer and check that it appears in their own list. An app that denies every request would fail this check.
- Try the attachment separatelyIf the booking has a photo, check that the owner can open it and that the second account can’t request its download. Use the app’s normal file access for each account. A successful save in an administrator dashboard leaves these customer permissions untested.
Could you get a deleted booking and its photo back?
Find out where the appointment record and the original photo live. A backup can bring back the record that points to a photo while leaving the photo itself missing.
Try recovering a made-up booking in a separate copy. Open it as the original customer and check that its attachment loads. If you depend on sign-in, include the accounts and sign-in settings in the exercise. Before changing live data, make sure you can recover the newer valid bookings and files you still need.
What changes the bill when people use the app?
Start with a day in your app. Count how many bookings staff might open, whether customers upload files, and how often those screens need new information. Different services charge for different parts of that day.
Firestore counts work such as document reads and writes. A screen showing a list of bookings can read several records in one visit. Neon counts how long the database runs at a given size and bills for stored records and recovery history separately on paid plans. On a hosted backend, check what your plan includes for sign-ins, file space and data sent to visitors.
If you run the backend yourself, price the computer, storage that survives a restart, backup space and email delivery. Make sure someone has time to install updates and help recover the service when it breaks.
Which features are worth adding later?
Add something when you can see what it would change. A shop with two staff members may want new bookings to appear without a refresh. A shop that takes deposits may need code to confirm a payment before reserving a slot.
If you expect to move the app, ask how to take the records, accounts and original files to another service. Save the access rules and settings your app depends on. A format you can export today is useful when the replacement can read it and you can show that a customer still gets the right booking.