Which is better, Google Firebase or AWS Cognito?

Google Firebase is an entire platform for building apps with authentication, hosting, a database backend, storage, analytics and more.

AWS Cognito is not a platform, it’s only used for authentication and identity management. The AWS product that competes with Firebase is AWS Amplify.

If you’re only comparing Firebase Auth with AWS Cognito, then they’re both very similar and offer 90% of the same functionality. Both will do fine in simple username (or email) + password sign-in, along with federated logins using Google, Microsoft, Facebook, and other social accounts.

AWS Cognito offers more advance

Google Firebase is an entire platform for building apps with authentication, hosting, a database backend, storage, analytics and more.

AWS Cognito is not a platform, it’s only used for authentication and identity management. The AWS product that competes with Firebase is AWS Amplify.

If you’re only comparing Firebase Auth with AWS Cognito, then they’re both very similar and offer 90% of the same functionality. Both will do fine in simple username (or email) + password sign-in, along with federated logins using Google, Microsoft, Facebook, and other social accounts.

AWS Cognito offers more advanced functionality by giving you a standalone site for OAuth and OpenID Connect redirect endpoints. Firebase Auth does not have this and relies on you to provide your own site using their Firebase JS-based UI components.

AWS Cognito also has more backend functionality for user attributes, profile mapping, security rules, lambda processing events, and backend integration into IAM. This is because Cognito is a standalone identity product which makes it easy to add app clients and API resources for a well-built token authentication system.

Firebase is more of an integrated offering into Firebase and meant to be used as part of the “apps” inside a Firebase Project, but it’s not really designed to handle multiple protected API endpoints and clients.

So if you need advanced authentication, standalone OIDC endpoint, tokens for multiple protected API resources accessed by multiple clients, then Cognito is a good choice. If you just need simple password or social login for a few apps, then either will work.

When considering pro and cons we can talk about the services offered and ease of implementation. With Cognito you get access to all the Amazon stack and especially Lambda which are only beta on Google side. Pretty much every other Amazon service has a Google equivalent.

With Firebase you get access to all their stack which target particularly mobile platforms and give you a realtime database, cloud messaging, analytics… You need to keep in mind though that most of these services would only work on devices that have Google Play Services installed which exclude Amazon devices for instance.

Which i

When considering pro and cons we can talk about the services offered and ease of implementation. With Cognito you get access to all the Amazon stack and especially Lambda which are only beta on Google side. Pretty much every other Amazon service has a Google equivalent.

With Firebase you get access to all their stack which target particularly mobile platforms and give you a realtime database, cloud messaging, analytics… You need to keep in mind though that most of these services would only work on devices that have Google Play Services installed which exclude Amazon devices for instance.

Which is better?

All in all and as always this depends on the stack you use or the one you want to use. Amazon being more popular in this area you’ll probably choose Cognito to integrate with Lambda and API Gateway for the API side of things and with Firebase for analytics, remote configs, cloud messaging and the real time database.

As William Lin said, your choice is entirely up to personal preferences. Google Firebase and AWS Cognito are both very efficient, and there’s few reasons to choose one over the other when considering basic elements they share.

I would say the only caveat to this would be that, if you are using AWS in general, it’s probably a good idea to stay inside that ecosystem. There’s a myriad of reasons for this, including ensuring proper system configuration and making for easier management, but overall, it just makes sense to stick with the ecosystem as it currently is rather that complicating it for wh

As William Lin said, your choice is entirely up to personal preferences. Google Firebase and AWS Cognito are both very efficient, and there’s few reasons to choose one over the other when considering basic elements they share.

I would say the only caveat to this would be that, if you are using AWS in general, it’s probably a good idea to stay inside that ecosystem. There’s a myriad of reasons for this, including ensuring proper system configuration and making for easier management, but overall, it just makes sense to stick with the ecosystem as it currently is rather that complicating it for what is essentially mirror functionality.

Actually its depend on your requirement. I used AWS cognito for Identity management and user pools.

Personally Its a good choice if you are working with other AWS services like Lambda function or dynamoDB. It would provide you flexibility to work with AWS services smoothly by using SDKs.

But I am not happy with Cognito SES email service, this is limited to only three regions and becase of this I had to use different API itself.

without using SES service you can not send confirmation or verification emails from your custom email address.

I love Google Firbase and it is an overall great platform. But it depends what you are looking for. I think Firbase is great for beginners and android developers since Firebase is built right into Android studios. AWS Cognito is also great and has a lot of customizability. Both will get the job done. It's up to preferences and personal opinions. I use both so I won't take any sides.

I’ve only worked with Google Firebase and I won’t change it for nothing.

  • Realtime database
  • Storage
  • Hosting
  • Crash Reports
  • Cloud Messaging

And this are only a few of all the features that Firebase can offer, so I’ll personally go with them.

I have personally used AWS, Google Cloud as well as Firebase for various projects. I am not associated with either of the companies. I am summarizing my experience with the services here:

  1. AWS has a whole lot of services (almost anything you can think of), they basically convert many open source solutions AS-IS to cloud along with adding billing. Most of the services (except few) are services where you would still have to think of capacity, traffic etc. Something that requires a decent sized infrastructure team. Billing is (usually) complicated, some services have various tiers, different ways y

I have personally used AWS, Google Cloud as well as Firebase for various projects. I am not associated with either of the companies. I am summarizing my experience with the services here:

  1. AWS has a whole lot of services (almost anything you can think of), they basically convert many open source solutions AS-IS to cloud along with adding billing. Most of the services (except few) are services where you would still have to think of capacity, traffic etc. Something that requires a decent sized infrastructure team. Billing is (usually) complicated, some services have various tiers, different ways you can buy instances etc. If not used properly can potentially incur a lot of cost.
  2. Google Cloud also has a lot of services (but fewer than AWS) but I find that they are more advanced technologically (Bigquery, Image/Text/Voice apis etc.). Many of google services are geared towards autoscaling, automatic traffic management and low IT costs. Billing is usually simpler and consequently google tends to be cheaper at scale as well, particularly if you are a small team putting together a fast product. (At-least it was cheaper for me)

Firebase although did not start @google, adheres to some of the principles google tries to have in its cloud products. It is a backend as a service, requires very little server side code if at all. It scales/load-balances without any intervention from you. Support is very good, they respond quickly. There is a lot of library support as well from the open source community. The best part(s) about firebase are 1.) It is built over websockets so you can actually build realtime applications with ease. More importantly you can actually give a real-time feel to even traditional applications. (think gmail vs yahoo mail in 2004) 2.) Billing is very easy and straightforward and in my opinion quite low cost esp. after google started backing it.

It is standalone you can combine it with any backend AWS or google if you need to. So the choice is not really AWS vs Firebase.

In fact you can combine the good features of each cloud and not really have to choose between aws vs something.

AWS Cognito is a simple service provided to manage all user creation and management task. As these days every other App/Website provides an option to create an account and log-in into the same to get personalized offers/services based on their previous consumption of services and other activities.

The base requirements for any user management service start at :-

  1. Having a “Database” were all the accounts’ Username/Passwords are stored
  2. Another Database where every individual accounts’ previous and current activities logs/data is stored so that it can be analyzed and interpreted to predict unique ha

AWS Cognito is a simple service provided to manage all user creation and management task. As these days every other App/Website provides an option to create an account and log-in into the same to get personalized offers/services based on their previous consumption of services and other activities.

The base requirements for any user management service start at :-

  1. Having a “Database” were all the accounts’ Username/Passwords are stored
  2. Another Database where every individual accounts’ previous and current activities logs/data is stored so that it can be analyzed and interpreted to predict unique habits and possible services every account can/might consume.
  3. Then you need to provide another functionality of integrating third-party accounts sign-in/log-in so that those who don’t want to create another new account can log-in/sign-in using their existing Google, Facebook, Amazon Accounts.
  4. The list just does not end, there is so much that you can provide above this and end user demands just keep on increasing.

Now, to fulfill these requirements, previously either Developers used to manually code these functionalities in their apps/websites and manage these Databases or simply use AWS Cognito. Some of the features are listed below:

  1. Helps to securely manage and synchronize app/website data for users across their Devices.
  2. Can create unique identities for users through a number of public login providers like Google, Facebook, Amazon accounts as well as supports unauthenticated guests.
  3. Can save app data locally on users’ devices allowing applications to work even when the devices are offline.
  4. Can save any kind of data in the AWS Cloud, such as app preferences or game state, without writing any backend code or managing any infrastructure.

For more details about AWS Cognito, you can checkout my blog of AWS cognito – Your User management Companion.

Because Parse is shutting down end of January 2017, it might sound like not a good idea.

BUT, Parse has open-sourced their platform code, mobile sdk’s, and even the web dashboard that can be used to manage the data and even manage push notifications.

If you don't want to deal with back-ends at all, not-parse is the way to go. If you're planning on scaling your application(s) and creating a legitimate business, Parse can be a great option to bootstrap a custom BaaS of your own in a manner of minutes (if you know what you're doing. It took me a couple days because I don't know what I'm doing). You

Because Parse is shutting down end of January 2017, it might sound like not a good idea.

BUT, Parse has open-sourced their platform code, mobile sdk’s, and even the web dashboard that can be used to manage the data and even manage push notifications.

If you don't want to deal with back-ends at all, not-parse is the way to go. If you're planning on scaling your application(s) and creating a legitimate business, Parse can be a great option to bootstrap a custom BaaS of your own in a manner of minutes (if you know what you're doing. It took me a couple days because I don't know what I'm doing). You can then run this bootstrapped backend on your own AWS instances, scale it up and down to keep costs low. There was any a price cliff like other BaaS services have where you end up paying thousands of you end up succeeding.

Then in the future as you grow, any back-end dev that knows Node.js can come in and continue scaling your platform, and the accompanying dashboard, and client sdks to do whatever you want.

So which is better? Depends on what you wanna do. If you want a legitimate company eventually around your product, Parse is EVEN better now that they are shutting down, because they are being so generous with their technology. Not to mention the community that is cropping up around these open projects to ensure that quality is maintained as time passes.

You should define what you intend to do with them, first.

Based on the stage of your product development, size of your user base, quality requirements, and design intention, each product would fill a need that’s going to either help with your goals or not.

Firebase is great for early stage development and getting your product off the ground fast.

Google Cloud Platform/Azure and AWS are supermarkets of your infrastructure needs. Unless you know the landscape of these tools, they’re overwhelming and not helpful. But in the hands of an expert, they are incredibly useful.

Unless you defined what your

You should define what you intend to do with them, first.

Based on the stage of your product development, size of your user base, quality requirements, and design intention, each product would fill a need that’s going to either help with your goals or not.

Firebase is great for early stage development and getting your product off the ground fast.

Google Cloud Platform/Azure and AWS are supermarkets of your infrastructure needs. Unless you know the landscape of these tools, they’re overwhelming and not helpful. But in the hands of an expert, they are incredibly useful.

Unless you defined what your needs were, all of them are going to be probably good or bad for you, but the certainty with which anyone could answer that questions is going to be rather low.

Disclaimer, I´m a founder at Back4App. I will detail below the differences between Firebase and Back4App plans.

Free Tier – Both Back4App and Firebase have a free tier.

Paid Plans – Back4App first paid plan starts at $4.99. Firebase first paid plan starts at $25.00.

Please see comparison below:

Back4App

Free

Startups $4.99 / month

Growing Apps $14.99 / month

Keep up scaling $34.99 / month

Momentum $49.99 / month

SMBs $99.99 / month

Firebase

Free

Flame - $25.00 / month

Blaze - Consumption based

Payment – Both Back4App and Firebase work with credit card payment. Back4App has only pre-paid plans. Firebase has p

Disclaimer, I´m a founder at Back4App. I will detail below the differences between Firebase and Back4App plans.

Free Tier – Both Back4App and Firebase have a free tier.

Paid Plans – Back4App first paid plan starts at $4.99. Firebase first paid plan starts at $25.00.

Please see comparison below:

Back4App

Free

Startups $4.99 / month

Growing Apps $14.99 / month

Keep up scaling $34.99 / month

Momentum $49.99 / month

SMBs $99.99 / month

Firebase

Free

Flame - $25.00 / month

Blaze - Consumption based

Payment – Both Back4App and Firebase work with credit card payment. Back4App has only pre-paid plans. Firebase has pre-paid and consumption based plans.

Tailor Made Plans – Back4app offers tailor made plans. Firebase does not offer.

Cost Variables – The main variables used to price Back4App and Firebase plans are Database and File storage.

Database Storage – Both Back4App and Firebase charge by GB used.

File Storage - Both Back4App and Firebase charge by GB used.

API Calls, Upoload and Download – Back4App charges per total API call / month and requests / second. Firebase charge by Upload and Download.