Should I use Firebase as a backend service for a social media app in iOS?

Short story, yes!

You want to create your MVP and I think Firebase is the perfect option for that, It gives you A LOT out of the box so you can focus on building your app.

One cool thing I like about its native mobile SDKs is that they offer offline support, if your users loose connection the app will remain responsive the entire time and sync the data once connection is back :-)

To quickly answer your question, Yes, Firebase is a good option to build a social networking app with. There are a lot of reasons for this (real-time database, documentation, support, code quality etc) but I am going to be focusing on the points you have specifically raised:

  • Is it safe? Yes.

Firstly safe is a very relative term. Ever wonder why you often see businesspeople using Blackberry phones? This is due to it being extremely secure. Blackberry was the go to for banking and sensitive information. Other phones were safe enough but weren’t the gold standard.

This is a similar situation with Firebase. Firebase has complex security rules which allow you to tailor your security specifically to your app. Your understanding will determine how complex the rules are and how secure your information will be. Would I use Firebase to store my credit card details? Probably not. But they are certainly good enough for most of the expected information shared in a social network.

  • Security Rules

Firebase gives you control of your database and control of the security of your data. Checkout their security rule documentation if you haven’t already.

Firebase’s security rules allow you to choose who can read and write information to the database. If a user doesn’t have the right to view or edit data then they can’t. Changing the java script does not affect these security rules which are set in your dashboard. For example:

  1. "rules": {
  2. ".read": true, // Anyone can read
  3. ".read": "auth != null", // Only an authenticated user can read data
  4. ".write": "auth != null", // Only an authenticated user can write

These are the most basic security rules. You can then set more complex rules based on specific areas of your data:

  1. "messages": {
  2. // Only thread members can read and write messages
  3. ".read": "root.child($root+'/threads/'+$thread_id+'/users/'+auth.uid).exists()",
  4. ".write": "root.child($root+'/threads/'+$thread_id+'/users/'+auth.uid).exists()"
  5. }

The above means that only users who are inside a chat can read and write messages to it. As you can see security rules are built on top of each other to increase the security your database has.

  • Is Firebase progressive?

Yes. You can develop an app on web and then create compatible Android and iOS apps to work along with it. There is a huge amount of documentation on this, all recreated for every platform.

  • Low budget/time/staff

Firebase has a free tier meaning you can set up and go. Compared to building your own custom server you will save huge amounts of time building, testing and modifying.

Building an application is not a quick process. If the project takes a long time then it will not be from using Firebase, rather because of the ambitiousness of the project.


Firebase is safe, free to start using and excellently documented and written. If you are unsure about any particular areas then post a question to their support team or on Stackoverflow. Here is an interesting one on where your data is stored and how secure it is.

If you want any help with setting up your project data structure you should checkout our companies open source chat components on Github. The data structure would be extremely similar and we have security rules which are included meaning you can ensure your information is safe. They are also compatible on iOS and Android meaning you could see how the structure fits together if you develop native apps.

Note: You can access the security rules terminal in your dashboard by using the below menus:

The only problem you will have with investors the moment you tell them you are using Firebase is that they will take a good hard look at them, and decide to invest in them instead. Because selling shovels is more profitable than prospecting for gold.

If you are using Firebase you should at the very least be cognizant that you need to monetize your fabulous mouse trap. Tools provided, and I assume you have monetization to go along with all the analytical tools that Firebase provides to delight your potential investors/acquisitors.

Doing the monetization bit is hard, as in building the tools are hard.

Doing the analytics in house is harder still. It requires real skill. You cannot improvise that kind of skill. And it could take you tears (typo for years) to personally develop those tools, and learn how to use them.

And the bottom line is that you should only be concerned about your value proposition and its monetization (potential or not).

Because if somebody wants to buy an app instead of reverse engineering it, the fundamental value proposition in its market vertical is the only thing they care about. That and time to market. Which means they will not mess with hiring the team and trying to execute on it themselves.

Investors (or corporate purchasers) don't invest on the basis of return. They invest/purchase on a risk adjusted basis.

Lastly, the only thing of value on the balance sheet is the trade mark equity. Don't let anybody tell you otherwise. Among the accounting challenged that is called the brand.

The opposite argument is that nobody is going to pay stupid money for something they can reverse engineer. Running proprietary scripts all the way through the engineering stack, makes entry and duplication much much harder.

You need to accept that somebody will legitimately make that argument. I aint buying, but I am absolutely certain that some dim-witted corporate drone has made the argument to his bosses. Which Miss CEO promptly dismissed with prejudice, on a risk adjusted basis.

Your risk adjusted basis is:

You have to recruit six people with all the necessary technical skills.

You have to recruit another six people to market and sell the mouse trap.

And you have to execute on the basic technical proposition without having verified if your business proposition is sound.

Then you have to execute on your marketing and business plan on the basis of untested technology at volume.

You will have to convince all your peeps to work for peanuts and options to purchase stock at today’s price, for the next eighteen months… GOOD LUCK WITH THAT.

And of course money only grows on the top of the tallest trees, and you look like an ant eater not a giraffe. So God Speed on finding the cash to run your engines as you go up and down down the runway trying to find lift…

So on a risk adjusted basis, 3 months and one quarter the personnel is a far better proposition than 18 months with a large burn rate and a massive execution risk. Because shit happens, often. And when you pay in peanuts you get monkeys: “Sure I can do that…”

So I poured twenty grand into restoring this eighties car I really loved. !@#king Italian sports cars… I might as well develop a coke habit with the hood ornament to go along with that…

Where were we? Ah yes. So I put out five for the car. And twenty for the restoration. Then I find another beauty I want to put my greedy sweaty palms on. And so I list the bad-girl on the net’ and the best I got is fifteen.

Three years later the car is now worth thirty.

Do the math.

The same applies to business propositions. If you invest $2m and two years of tears and blood, that does not mean you have a 2m proposition. Because investors don't invest on opportunity cost. They invest on a risk adjusted basis.

And if a corporate wants to buy your gizmo, lock stock and barrel, they will do so on the basis of the return, or more likely on the basis of the value of your contribution to the perceived value of the corporate stock. Because they are payed in options, and unless something bumps up the value, they cannot profit from the transaction themselves.

So why would you spend money you have no idea you can ever get back? That is the basic proposition for using a tool integrator (and if I was the bastard running Firebase I would put a contract out on me immediately for calling them an integrator…). Speed of execution is everything because building your own tools takes time. And if nobody wants your mouse trap, why spend the money building the tooling to mass produce it?

Speed of execution is EVERYTHING.

Your question presupposes weakness. And the weak get crushed in the market for ideas.

Because what you are saying is that you are done with your project, you have lost interest, and have no intention of doing the dirty work of marketing it, selling it, getting customer feedback and iterating on it. Your are saying you are done.

“I have built it! And so can somebody please sign over a check for a couple of gazillion dollars, because I got better things to do with my time…

And this is the bottom line. You cannot sell an app. Nobody is going to buy it.

If the app has true value to users and one of your competitors decides on a risk adjusted basis that its cheaper for him/her to buy you out, they will come knocking on your door and take you out of your misery.

So no, you cannot sell an app. But you can certainly buy one. Lock stock and barrel and hopefully with the chief nerd in golden handcuffs for six months.

But first things first, build value your users/customers love and love to refer. Because unless you have that, you have nothing of value, regardless of how it was built.

Thanks for the ask, and good luck.

First, when talking about databases in the Firebase suite, I’m only going to talk about Firestore, and not RTDB (Realtime Database, which was traditionally known as just Firebase). Firebase now refers to an entire suite of services, which includes Firestore, RTDB, file storage, authentication, etc. RTDB is most likely going to be phased out and Google is clearly putting their effort behind Firestore.

Second, there is no manual sharding in Firestore, like there was in RTDB. Sharding is handled automatically by Firestore, so ignore the other answers about that.

Third, you, the customer, own the data in your Firestore database, not Google, so ignore the other answers about that also. If Google, and not the customer, owned that data, Firebase would have virtually no users. And, also contrary to the other answers, you can export data from Firestore. If customers weren’t allowed to export their data, who would ever use it?

Fourth, the suggestion to use SQL technology on your own physical servers (ones that you physically own) is not something that I think belongs in an answer to this question. SQL vs NoSQL and cloud vs in-house are decisions that you should have already made if you’re asking about a specific serverless provider. Clearly (at least apparently), you’ve decided on serverless NoSQL, which is definitely the most popular choice today. And between the two most popular providers, AWS and Firebase, they are designed to handle virtually any workload you throw at it. The most highly-trafficked applications in the world run on NoSQL serverless, like the Amazon marketplace, for example (AWS, obviously). If AWS can handle it, Firebase can handle it too. Google would never design its NoSQL serverless to max out at a certain number of users or level of traffic; it’s designed to scale virtually infinitely.

The only caveat to Firestore (and NoSQL serverless in general, really) is dollar cost—right now in 2019, anyway. Firestore was considerably more expensive only a year ago than it is today, think about that. I think NoSQL serverless will undoubtedly continue to become cheaper, including Firestore. But, right now, with a relatively large userbase, NoSQL serverless, like Firestore, can get expensive. But so can doing it all in-house. An in-house solution still comes with bandwidth cost, in addition to hardware and human cost. Hiring qualified backend engineers to build and maintain an in-house setup is not cheap (hundreds of thousands of dollars a year). Firestore (and DynamoDB) have excellent price calculators to help you predict your costs and you may be surprised to see how cheap it is with a modestly-sized userbase, even with 100k users.

This is a question I get from a lot of clients as many of our products rely heavily on Firebase. The answer is very dependant on your application but in almost all cases this will never be a problem.

Where do the costs occur?

If you look at the Firebase pricing plan you can see that data is the main constraint for the pricing brackets. When you move up a tier you get various increases in data allowances as well as more database operations. This means you need to look at what your app does to see the impact of more users.

What does my app do?

This is the next question you need to ask yourself. Many apps will be dealing only in text strings meaning the data amount is very small. Images would be a step up from this and videos another jump in data usage. You need to think about how often your app stores this data. It might be that you only upload a single image for each user or it could be that you send multiple images while using. In both these cases the data usage will vary hugely.

Before worrying about how you will cope with 1M users think about how the app will fare with 1–10k users. In Firebase’s case you will probably be on the free tier (as long as you are not guzzling data) up to 100k users.

Think about this for a moment. You will have 100k users on your app. Even if you only add advertising you should be able to make the $25 a month to cover the Firebase FLAME costs.

The motto I use with my clients is this:

By the time you need to start worrying about backend costs for your app you can stop worrying about backend costs for your app

Once you reach the amount of users to requiring you to start payment you will have a successful app with a big user base which can be leveraged to start paying you back.

Should I use Firebase?

This is the final question you should ask yourself. Up until now this question could have been about one of the many different backends on offer.

If you are unsure I would be inclined to say: YES use Firebase!!

They are a great company and offer a fantastic product. Being owned by Google and having recently updated all their code they are unlikely to close down (RIP Parse). They also provide extensive and clear documentation and great support. There is a huge online community meaning sites like this and Stackoverflow have a huge number of questions to help you.

It is worth looking at your app though. Firebase does have some disadvantages:

  1. There is no easy way of querying data
  2. There is no way of executing code on the server

This is what should be researched when looking at whether Firebase is the right backend for you and even these can be mainly mitigated by using a separate server to control these tasks.

Conclusion: Unless your app is very data intensive then you won’t meet any of the data caps. Firebase will help you get your app online quickly and cheaply before scaling excellently once the users start pushing the upper limits.

NOTE: I would never recommend someone building their own backend when starting a new app. It might be that you have the skills to do it but in the long run it will cost you more (in your valuable time) than using another provider. Once your app is a great success and you are paying monthly fees to a backend then you can invest the money in creating a custom backend which suits your data type. Creating it yourself also requires a huge amount of invested time. If your app fails then this time is completely wasted.

Yes it can be done but it’s stupid! Read on and learn why. It all comes down to the complexity of operations we’re going to run on our data. In the case of Instagram what we usually want to achieve is loading the news feed. This is a problem with Firebase, let’s see why. A newsfeed is (in a naive way) a list of posts of people I’m following. In a relational database I would simply select all rows from table post, join them with the follow table and sort by timestamp (very very naive, we’re omitting “relevance” but this is ok for simplicity). That’s basically it. If you want to scale this out you’d probably want to introduce sharding before your database explodes but this is another topic. Let’s get back to Firebase, which is a massive scalable json store. In order to understand the problem you should have a look at the pricing table: Firebase Pricing 100K concurrent connections for the Realtime Database is ok at the beginning, the problem lies in storage costs and pay per data transferred. If we translate this into a graph it would look like this: The more data you store and the more data you transfer the more it costs you. If data stored and data transferred were to increase linearly this would be ok, but this doesn’t make sense for a platform like Instagram. Once Instagram kicks off what you’ll see is people with millions of followers, generating content with millions of likes etc.. Why is this important? The business model of Instagram is based on network effects. You’d always want to achieve exponential growth which, and this is the critical part, would directly translate into exponential costs when using Firebase. This is because with Firebase Realtime Database you cannot simply “join” a newsfeed together. You will have to heavily denormalize your data and re-join it at the application level. If you want to achieve near realtime news feed functionality you’d have to accumulate all posts that should be shown in a user’s newsfeed, put them into a json array and store it. This increases data stored exponentially! Now think of adding “likes” to the posts. You could either update all denormalized posts which will increase data transferred exponentially or you can store likes centralized and make one request per visible post. The latter would increase data transferred even more and leads to a poor user experience. To sum up: Firebase Realtime Database is an excellent tool to reliably store json data. When it comes to heavily relational data like “social network data” you’re going to pay a lot of money to achieve the same results and you’ll have to implement a lot of logic into your application layer to correctly accumulate the data required in the frontend which is prone to errors. It could have been done but it would have never scaled.

Yes it’s an excellent choice.

  1. Performance: Excellent
  2. Learning curve: Minimal
  3. Cost: not bad (as long as you structure data and build your app right)

When you think about hosting cost though, consider how it might be offset. Were you to build your app with a more labor-demanding technology with cheaper hosting, you might need to keep some expensive developers on the payroll. With Firebase, a small team (or one person) can keep things under control. Hosting alone is a small part of the cost of owning a production website.

You need to ask yourself two serious questions before investing too much in Firebase though:

  1. Do I need to perform complex queries?
  2. Will I be heavily reliant on back-end code?

Firebase queries are pretty much like this: “Hey Firebase, give me the data at this node” and you get back raw data. You can maybe sort or limit, but probably not in any complicated way natively.

Firebase does not (yet anyway) provide a direct path to modifying the back end code. You can certainly write your own back end, especially if you use Node.js, and there are several ways to architect your app with it. To launch a chat app though, you don’t really need to worry about that.

You say it’s “in order to launch a startup” and you say you already know how to build a chat app using Firebase. In a sense there’s your answer right there. In general if you have an idea you want to implement and a clear path to move on it, take the path available to you. Even if you knew how to build it with other tech, I still might suggest Firebase due to the easy learning curve and the advantages of a real time database.

You’re open to learning new things. That’s great! You’d be a fool to be closed to new skills. When (if) your app scales to a point where the limitations of Firebase come into play it should be pretty easy/smooth to migrate away. Firebase is so light-weight and flexible that you could literally re-build your app full stack with other technology and then just plug it into your old Firebase as a quick-fix, then take your sweet time building out a new database and query structure.

There’s a pretty good chance you’ll never do that though. If your app really is limited to chatting, you’d be hard-pressed to run into a wall with Firebase. Some of the smaller limitations can be overcome by building a node.js “reactor” type server that just listens to Firebase for changes in data, then reacts in some way. You could also supplement Firebase with an API in that same or a different supplemental server.

Please don’t listen to the “proprietary blabla”. This is bs.

Imho MBaaS is the biggest failure ever made. No one ever will make money (long term) out of it. Their biggest failure, as you see in this post is, they don’t understand people like you. They think you will be a paying customer at some time. (This is never going to happen)

Now, let’s solve your problem. You’ve got that great idea and want to get going quickly. You seem like passionate about it. You want to focus on front end, not backend, means you focus and know your weaknesses. Very good point to start at!

So, why is Firebase your perfect solution? It’s supported by google. It’s super super easy to use. It’s well documented. Any more questions?

You can build whatever app (prototype) with Firebase in no time. It might not scale, but this is not what’s it about. You just want to master front-end stuff, don’t you? Right.

Eventually your MVP might get traction. What are you going to do? Well, if it’s going to get “a lot” of traction, you can pay someone to build a scalable backend for you. If not, scalability will never be an issue. You just don’t have to care about it!

Build whatever you like. Focus on the things you love to do. Firebase let’s you do exactly this. Keep it going, cheers.


1. If your app does run of a centralized DB, and is updated by a lot of

users – then it’s more than capable of handling the Real-Time data

updates between devices.

2. Stored in the cloud so readily available everywhere.

3. Cross Platform API (If you are using this DB with an App)

4. They Host the data. -Meaning if you are storing a lot of data, you don’t have to worry about hardware!


1. Unless your app runs of one centralized database updated by a vast quantity of users, it’s a major overkill.

2. Storage format is entirely different to that of SQL, (Firebase uses JSON) so you wouldn’t be able to migrate that easily.

3. Reporting tools won’t be anywhere near the ones of standard SQL.

4. Costs! -Limited to 50 Connections and 100mb of Storage!

5. You don’t host the data, Firebase does. And depending on which server you get put on, viewing there up time there seems to be a lot of disruption lately.

Read more at: What are the advantages and disadvantages of Firebase for a database? - FAQs System

Yes but you will burn way too much money. Why?

Firebase is a general purpose very easy to use Api and so are the features. Very easy to use but not too rich of functionality. (you cannot get complex queries with Firebase e.g.)

You will easily build a Instagram Clone. However, at a certain point it’s simply too expensive and you’re better off developing your own stack to serve your needs efficiently.

Conclusion: Build an MVP with Firebase if you have no idea about backends. If your app gets traction you can easily transition to your own stack. (Most of the times you won’t get traction so there’s no need to waste time implementing your own stack)

Why would you build out a backend if you could start working with one immediately, at no cost, with no maintenance? If your app is lucky enough to scale bigger than what Firebase could offer (and that would be an excellent problem to have), you could always move to a more sophisticated cloud offering, such as Google Cloud Platform, what that time arrives. No need to put a lot of effort into something today unless you are absolutely certain you will need it.