What is Firebase Review: Why Developers are Fired Up About Firebase


Firebase has been growing fast since Google acquired it in 2014. Developers praise it as a way to keep up with technical demands of modern enterprise.

The powerful mobile and web app development platform provides a healthy suite of tools for building and growing highly scalable apps, all within a shorter time frame that fits digital transformation efforts.

What exactly does Firebase bring to the table? Here are the five features most commonly cited by its community of supporters.

What is Firebase?

Firebase is a “backend as a Service (BaaS)”, meaning there is no server infrastructure needed. This shortens development time and removes a layer of complexity for developers.

The best thing about BaaS, though, is that it frees developers from the tedium of building out a backend. Instead, they can direct all of their focus to creating dynamic, user-oriented apps.

Firebase has a Huge Feature Set

One of the Firebase’s biggest draws is its robust, well-tested feature set. It has tools for nearly everything a developer could need. Some, like Google analytics, are built in free.

Other can be incorporated as needed, such as:

  • Authentication
  • Hosting
  • Push notifications
  • Real-time messaging
  • Cloud storage
  • Performance monitoring

These can all be used independently of each other. Developers have the option to buy only what they need instead of getting locked into a huge bundle they won’t use.


SQL databases are geared towards highly structured data. For less organized data like comments, photos, and reviews the flexibility of a NoSQL database is better.

Firebase handles large datasets and bi-directional references easily. That makes it a good choice for Big Data operations for which the object-oriented approach doesn’t work as well.

Firebase is Economical

Price is one of the most pressing priorities during development. Firebase lowers the initial investment by using a subscription service model.

The beginning tiers of Firebase are cheap or even free initially. Companies can publish their app and start working towards OIR much faster than when the backend has to be built from scratch.

There’s also the fact mentioned earlier, that developers can buy only what is needed at the time. That goes for both features and cloud storage.

By the time more storage is necessary, the app should be on its way to earning back its development costs

Firebase is Enterprise-Oriented

All of these qualities contribute to Firebase’s most compelling benefit: its focus on enterprise. The platform is optimized for the kind of real-time and streaming apps that help a company stand out among its competitors.

It’s startup friendly, enabling growing companies to build cross-platform apps fast and economically. Apps start small, with just a little cloud storage, and scale as their usage grows.

Plus, Firebase offers easy social authentication integration. Allowing customers to log in with their social media solves several pressing business problems.

Visitors stay on the site longer, share posts more often, and are shown targeted ads that improve their user experience.

Firebase Limitations

Some developers are understandably wary of platform dependency. While it’s true that Firebase has more tools for migrating than it did at launch, it’s still reliant on Google.

The Parse shutdown is still fresh in the industry’s memory, so this is a risk some prefer to avoid altogether.

Configuring the database and security settings are on the complex side. It takes a Firebase expert to set it up without accidentally making sensitive sections public.

There are the querying limitations common to NoSQL to think about, too.

Long-term cost is another consideration. At lower levels it’s inexpensive, but at scale it can get pricey.

Final Thoughts

Firebase is a dynamic platform with a lot of potential. No tool is perfect for every situation, but where Firebase fits it serves as a welcome shortcut for companies trying to work through their development priorities.

Could Firebase be the platform you’re looking for? Schedule a free consultation with one of Concepta’s developers to discuss your new project and whether Firebase is the right fit.

Request a Consultation

NoSQL vs SQL: Which is Right For Your Project? [INFOGRAPHIC]

nosql vs sql

As technology advances, the difference between NoSQL vs SQL databases can do are blurring. Developers flood tech forums with clever workarounds that let them stick to their favorite database, even when it doesn’t exactly fit.

This is a source of confusion for the c-suite seeking guidance on the best database for a specific project. No matter how hard the internet crowd argues that an experienced programmer can make any database work, there are very real structural differences between SQL and NoSQL.

Workarounds that disguise these differences result in unnecessary complexity, decreased performance, and higher development costs.

So how should a responsible leadership team choose? Start by brushing up on the benefits of both formats.

SQL: Orderly and Secure

SQL refers to relational database management systems (RDBMS) written purely in SQL. Data fields are organized into structured tables, and creators must clearly define the schema before adding data.

The rigid structure of a SQL database has some major advantages.

Advantages of SQL

Data Integrity

The format emphasizes data integrity by minimizing redundancy, normalizing data, maintaining referential integrity, and enforcing strict constraints on what data can be entered or altered.

Better Control

Using a SQL database provides better control of transactions compared to NoSQL databases.


A hyper-organized SQL database is also easier to query.

Handling large amounts of structured data

It’s suitable for projects with a large amount of structured data that needs to be regularly referenced and analyzed by non-engineers.

Anyone who knows how to structure simple SQL queries can pull information from the database (within the permissions imposed upon them by the administrator).

Community Support

SQL databases have been on the market for a long time.

There’s a large community of users, so support is easy to find.


With many skilled developers and database administrators available, upper management can afford to be choosy about who they contract with or hire to handle their SQL database.

Disadvantage of SQL


The biggest drawback to an SQL database is its price.

Hosting and licensing fees are generally higher than with NoSQL databases. Most companies offer bundle discounts, but costs rise when developers want to mix and match products to more precisely suit their needs.

The leading RDBMS, Oracle, changed its pricing structure in January so that hosting with Amazon Web Services or Azure is significantly more expensive.

However, open source options like PostgreSQL or MongoDB can keep the price within an acceptable range.

NoSQL: Fast and Flexible

The name “NoSQL” is a bit misleading. It means “not only SQL” rather than “no SQL”. In a NoSQL database, data is stored in documents that contain loosely related chunks of information.

Developers don’t need to create schema before adding information; data can be dumped into the database and organized once it’s there.

Advantages of NoSQL

A NoSQL database is useful when the data requirements of a project aren’t clear up front, especially if it’s difficult to estimate how much of the data will be structured versus unstructured.

Use of Unstructured Data

Document databases are perfect for large volumes of unstructured data.

Fast Development

Document databases are ideal for rapid development. Installation is quick and easy. Because there’s less setup involved before adding data, they allow for fast, iterative prototyping.

IDEs are Abundant

In their infancy there weren’t many NoSQL tools, but today developers have a wide choice of integrated development environments (IDEs) to examine their data and run queries.


NoSQL databases are compatible with most development frameworks and platforms which provides flexibility in building the stack.


Plus, hosting is cheap on the production environment. Although a third party service is recommended afterwards, there are plenty of cost-effective cloud services to choose from.


Scalability is a powerful benefit to NoSQL databases. They are designed to be distributed across servers, making them scalable on short notice with little impact on performance.


Data is accessible and very fast compared to most common RDBMS.

Disadvantages of NoSQL

Dip in Quality

Of course, flexibility and performance come with a reduction in accuracy.

Not ACID Compliant

The majority of NoSQL databases are not ACID compliant. Many rely instead on the principle of eventual consistency, trusting that although data may be altered on one server it will become consistent across servers during the next update.

Number of Experts

Finding NoSQL experts may be tricky. There is a growing community, but since it’s a newer concept than RDBMS there’s a smaller pool of trained developers and database administrators. Some supporters have argued that the point of NoSQL is to do away with the need for a DBA, though in practice that isn’t yet feasible.

Making the Choice

As a general guideline, NoSQL databases shine when dealing with real-time big data, content management, and IoT applications. SQL databases take the lead in situations where complex queries need to be done often, as in online transaction processing and banking.

That said, asking whether a RDBMS or a NoSQL database is better without considering the project is futile. It’s about as helpful as asking whether to use a fork or a spoon before the meal has been ordered. Each project has unique needs. While SQL databases tend to be the default choice for developers, there’s no objectively “better” overall database philosophy.

To make the final decision, assess the scope of the project at hand.

Are the data requirements clear up front?

Developers can’t create schemas without direction. When there isn’t enough certainty about what type or how much data will be incoming, a NoSQL database may be the better option.

 How much JSON data will you be handling as a percentage of the total?

Few projects will have entirely one type of data. If unstructured data is a relatively small portion of the whole and other considerations make an SQL database attractive, the SQL database will be able to handle it.

What’s more important, data integrity or performance?

When data integrity is the overriding priority, use SQL. If not, NoSQL generally has a noticeable edge in performance.

Will you need to cache and share data often?

This is a particular strength of NoSQL databases.

Is this a global or a local app? How fast will you need to scale?

Scaling a NoSQL database is as easy as adding more servers. An RDBMS scales up, not out, making for a slower process.

Are there relevant legal or trade restrictions?

Projects that handle a lot of protected data, such as HIPAA information, need to prioritize security and data integrity.

Concepta NoSQL vs SQL infographic

Once all the information has been gathered, one database style should stand out as the better option. If that doesn’t seem to be the case, take the problem to the developer. There’s a variety of both SQL and NoSQL databases; one may have a set of traits that solves the apparent dilemma. For instance, if a NoSQL database seems like a good fit but consistency is fairly important, the developer may recommend a database such as MongoDB which is strongly consistent (though not ACID compliant beyond the document level).

Still unsure? Concepta can help! Contact us for an assessment of the best technology for your project.

Request a Consultation

What Is the Difference Between Relational vs NoSQL Databases?


Most people will tell you that NoSQL is cool. Just about any web icon you can name, including Facebook, Amazon and Google, run on a NoSQL database.

That’s all some people want to hear, but if you want to really understand and compare relational vs NoSQL databases, you’ll need a bit of background.

The Dawn of the Relational Database

Before 1970, databases tended to be hierarchical. They were built along the structure of a branching diagram, with entities firmly under each category. For example, spoons were categorized under silverware, which was also categorized under kitchen utensils. This kind of approach to information sometimes tended to be too rigid to capture subtle concepts like the spork or kitchen scissors.

Then E.F. Codd and his colleagues at IBM introduced a new kind of database in a paper called “A Relational Model of Data for Large Shared Data Banks.”

It certainly wasn’t a bestseller, but this discussion opened up an entirely new way of working with information for IT professionals. The idea behind the relational model is that the database’s schema, which is the logical organization of the information, is disconnected from physical information stored in the database. Categories can change and combine in original ways based on the search functions.

In this kind of information structure, scissors can be related to kitchen utensils but also to craft supplies. Answers depend on the questions the database administrator asks.

For the last forty years or so, this has been the new standard organizational model for all large scale data management tasks.

By the 1980s, the new standard way to pull information from these growing databases, which commonly resided on mainframes, was using a system of Structured Query Language (SQL). Components such as IF THEN statements, JOINS and variables made it easy to put up extremely detailed data on command, and databases expanded in size exponentially. That’s when relational databases began to be referred to as SQL databases.

Introducing the NoSQL Database

Non-relational, or NoSQL, databases never went away really, but they found new life after the turn of the millennium. The complex relationships and vast amounts of data required by search engine algorithms to find individual websites stretched the limits of queries. There have been many different approaches to cataloging data in new ways. Some of the most common types of NoSQL databases include:

Key-value stores

These are the simplest kind of NoSQL database, where each item has a key and a value. They are most often used today for managing session information for web applications. Ex: Facebook

Graph stores

These contain and manage information about networks of data, like highly complex socialconnections. Ex: Amazon’s Web Services

Wide-column stores or distributed storage

These manage structured data that can scale to very large sizes rapidly, such as petabytes of data across thousands of servers. Ex: Google

Which Is Better?

As you probably guessed already, the answer is, “It depends.” If you want to work on advanced data stack for handling big data, real-time analysis and vast supply chains, NoSQL is the only way to go. Queries take too long and use up too many system resources.

When you need to use a massively distributed computing resource, you want to consider some NoSQL options.

Conversely, if you are working with customer relationship management (CRM), internal document version control or content marketing, a relational database is fast and easy. SQL queries can be saved and modified simply, even without a lot of IT experience.

Of course, you always have the option to leave it up to the guys in development to decide which kind of database structure you need. They will certainly have their own preferences and experience with each.

For more information on relational vs NoSQL databases, please visit our website and contact our team today.

Request a Consultation