Case study · Migration
Case Study: Moving a D2C Food Store from Firebase to a Self-Hosted Go and PostgreSQL Stack
A direct-to-consumer brand selling dehydrated fruits, vegetables and powders first ran its online store on React with Firebase Authentication, Cloud Firestore and Firebase Storage, hosted on Vercel. We rebuilt it on infrastructure the brand controls: a Go API on PostgreSQL, self-hosted S3-compatible image storage, server-rendered product pages that search crawlers and AI readers can read, and a Razorpay payment adapter, all running in Docker on a VPS.
By Web Your Vyavsay team · Published
Drafted with AI assistance. Claims are checked against the sources listed below and reviewed by our team.
Before and after
| Before | After | |
|---|---|---|
| Front end | React and Vite, rendered in the browser | React 19 and Vite, with public pages rendered on the server |
| Back end and data | Firebase Authentication and Cloud Firestore | A Go API with a hexagonal architecture on PostgreSQL |
| Sign-in | Firebase Authentication, including Google sign-in | JWT access and refresh tokens, email verification and password reset |
| Files | Firebase Storage | MinIO, S3-compatible storage the brand hosts itself |
| Hosting | Vercel | Docker Compose on a VPS, behind Nginx with Let’s Encrypt TLS |
Why teams make this kind of move
These are the common reasons businesses move off a backend-as-a-service such as Firebase; they apply to many projects, not only this one.
- Orders, stock and reports fit naturally in a relational database that can be queried and exported freely.
- Owning the database and files means choosing where the data lives and moving it without a vendor’s export tools.
- Costs become predictable when they are a server bill rather than per-operation pricing.
- Server-rendered pages give search engines and AI tools the full product content, not an empty page.
What the rebuild added
- A cart saved on the server for signed-in customers, plus guest checkout.
- Product reviews and a wishlist.
- Razorpay payments, with a mock gateway for testing.
- Admin CSV exports for orders, users and bulk enquiries.
- SEO titles and descriptions managed per page from the admin.
- Bulk enquiry management for wholesale buyers.
Pages that crawlers and AI can read
A small Node service renders each public page to HTML before it is sent, so a search crawler, a link preview or an AI reader receives the product details instead of an empty container. If that service is unhealthy, Nginx falls back to the static app, so shoppers are never blocked.
Lessons for your own migration
- Keep your URLs, or redirect every old one permanently, so search rankings survive.
- Check whether your current sign-in provider can export password hashes; if not, plan a password-reset flow for existing customers.
- Move images and files along with the database records that point to them.
- Rehearse the move on a copy before switching the live store.
Frequently asked questions
Is Firebase a bad choice for an online store?
No. It is a fast way to launch, and many stores run well on it. Moving off it makes sense when you need relational reporting, more control over your data and costs, or server-rendered pages.
When should a business move off Firebase?
When reporting, data exports or costs become hard to manage, when you need data in a specific location, or when search visibility suffers because pages render only in the browser.
Can a store move off Firebase without downtime?
Usually with very little. Building the new stack alongside the old one, rehearsing the data move and switching DNS at a quiet time keeps the interruption short.
Who owns the data after the migration?
The business does. The database, files and servers sit in accounts in its own name.