"Should we use Firebase or MySQL?" is one of the first questions on almost every project we start, and the honest answer is that neither is better in general. They make different trade-offs about data shape, cost, real-time behaviour and where the code runs. This guide explains those differences so you can choose based on the project in front of you, including the hosting constraints that are common in Ethiopia.
What each one actually is
Firebase is a set of managed services from Google. The ones people usually mean are Firestore (a NoSQL document database), Authentication, Cloud Storage for files and hosting. Your app talks to these services directly from the client, protected by security rules, so you often need no server of your own.
MySQL (or MariaDB) is a relational database. You define tables and relationships, query with SQL, and talk to the database from server-side code such as PHP or Node.js. On shared cPanel hosting it is usually included in the plan.
Data shape: documents versus tables
Start with the data, because it drives everything else.
- Relational data fits MySQL. Orders that belong to customers, line items that belong to orders, reports that join several tables, totals and filters across many records: SQL is excellent at this.
- Hierarchical or per-user data fits Firestore. Chat messages in a conversation, a user's saved items, content with flexible fields that differ between records: documents map naturally to this.
- Reporting is the usual deciding factor. If you will constantly ask questions like "total sales by product by month", you want SQL. Firestore can do simple queries well but has no joins and limited aggregation.
Real-time behaviour and mobile apps
Firestore can push changes to connected clients instantly and supports offline caching on mobile, which is why it works so well for chat, live listings and apps used on unreliable networks. With MySQL you must build this yourself with polling, WebSockets or a separate service. If real-time updates and offline use are core to the product, Firebase saves a great deal of work.
Cost behaviour
Pricing models differ in a way that surprises people.
- Firestore is billed by usage: reads, writes, deletes and stored data, with a free tier. A badly designed screen that reads hundreds of documents on every load can quietly multiply costs as users grow.
- MySQL on shared hosting is a flat fee: a predictable monthly or yearly price, whatever the number of queries, within the plan's limits.
- Currency matters: Firebase usage beyond the free tier is billed in US dollars and needs an international payment method, which is a real barrier for many local organisations.
Estimate your costs before you commit: count the reads and writes of your most common screens, multiply by expected daily users, and compare against the pricing page.
Security models
With MySQL, access control lives in your server code: the browser never talks to the database, and your PHP or Node code decides what each user may do. With Firestore, the client talks to the database directly, so security rules are your only protection. Rules are powerful, but subtle mistakes are easy: allowing a message to be read does not mean it should also be writable, and ordering by a device clock instead of a server timestamp can reorder conversations. Whichever you choose, test your rules or permissions deliberately, including as the wrong user.
Hosting and operations
| Question | Firebase | MySQL on shared hosting |
|---|---|---|
| Server to maintain? | No, fully managed | Host maintains the database; you maintain the code |
| Scales with traffic? | Automatically | Within plan limits; upgrade needed beyond |
| Backups? | Must be configured (exports) | Host backups plus your own dumps |
| Works with static front-ends? | Yes, directly from the browser | Needs an API layer such as PHP |
| Vendor lock-in | Higher: proprietary data model and APIs | Lower: standard SQL, portable dumps |
This last point matters for long-lived projects. Moving a MySQL database to another host is a routine export and import. Moving off Firestore means redesigning data access and rewriting the client code that depends on it.
Team skills and maintenance
Pick what the people who will maintain the project can actually support. A small team comfortable with PHP and MySQL will move faster and make fewer mistakes with those tools than with a platform they are learning mid-project. Equally, a mobile developer who knows Firebase well can ship an app in weeks that would take months to build with a custom backend.
How we choose in practice
We use both, for different jobs:
- Android apps with chat, live updates or offline use lean on Firebase. SiraHub's authentication, listings and messaging are built this way; see Building SiraHub.
- Website admin systems on shared hosting often use PHP with MySQL or SQLite, because it is included in hosting the client already pays for and there is no foreign-currency billing.
- Static front-ends can be paired with either, depending on whether the dynamic part needs real-time features. See our static Next.js guide.
A decision guide
- Do you need real-time sync or offline support? Lean Firebase.
- Is your data highly relational, with reports and joins? Lean MySQL.
- Do you need predictable costs in Birr? Lean MySQL on local hosting.
- Is it a mobile-first app with no server team? Lean Firebase.
- Might you need to switch providers later? Lean MySQL, or isolate Firebase calls behind your own data layer.
The short version
Choose Firebase when real-time features, offline support and no-server simplicity matter most. Choose MySQL when your data is relational, your hosting already includes it and you want predictable costs and easy portability. Whichever you pick, design for the queries you will actually run.