26

I'm researching some backend-as-a-service (BaaS) solutions for developing web applications, and I constantly see that Firebase refers to their database as a "realtime database", while for example Backendless doesn't mention the phrase "real time" anywhere.

I understand that realtime means that the data is processed immediately, but I thought all databases did that? If I for example have a MySQL/SQLite/PostgreSQL database and insert data, I expect it to be available for retrieval within (milli)seconds later, and definitely directly after an "INSERT ..." query has been completed.

Can someone shed a light on what is so different about the Firebase realtime database, compared to other BaaS services "normal" databases?

Improve this question
9
  • 12
    Scroll down a bit on that page: "Instead of typical HTTP requests, the Firebase Realtime Database uses data synchronization—every time data changes, any connected device receives that update within milliseconds. Provide collaborative and immersive experiences without thinking about networking code". Clients don't have to poll, they get notified of data changes. Commented Apr 15, 2017 at 9:26
  • 3
    Ah okay, so the difference is not really about how quickly the data is stored, it's more about the fact that the database can send push notifications about changes to clients in real time? And with for example Backendless the clients would have to manually poll the database to see the changes? That makes sense, but it's a bit confusing name for it... I guess "Notificating database" or "Observable database" doesn't sound as catchy though... Commented Apr 15, 2017 at 9:36
  • 1
    A further source of confusion was that Wikipedia says that a realtime database uses "[...] timing constraints that represent a certain range of values for which the data are valid. That makes it sound like a realtime database is more like a non-persistent temporary cache than a permanent storage solution? I guess that's not at all what Firebase mean with their terminology? Commented Apr 15, 2017 at 10:05
  • 1
    Also, if the server supports HTTP long polling, isn't that effectively the same thing? Commented Apr 15, 2017 at 10:39
  • 3
    It's not "a realtime database". It is the "Firebase Realtime Database". It's just a product name. You might just as easily wonder what "a Firebase" is. Commented Apr 15, 2017 at 15:39

2 Answers 2

Reset to default
7

Term real time is little confusing but indeed Firebase is very different from normal databases. There are two main differences. First is the way it stores data and another is the way we access it. In normal database when data at back end get updated we need to refresh our browser or android app in order to get updated data, on other hand in firebase we don't even need to refresh the page. Changes done from any other client browser will reflected to all connected clients without making any server side call.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

3

It is seldom related to how people coin the name, "real time" or if it is offered as BaaS. If data can be retrieved much faster by optimising storage and retrieval, then it can be classified as real-time. E.g. of real time database Aerospike, SAP Hana, Volt DB, memcached, redis and SQLite.

Realtime or in-memory Database,

  1. Data stored in RAM. For reliability, data is backup on non-volatile memory. nvram might be used in future.
  2. Cost is higher.
  3. High Performance.
  4. No serialisation is required. As data is accessed using pointers.
  5. Uses AVL tree(or other optimal data structure) for indexing to support range queries.

RDBMS "normal" Database,

  1. Data stored in Hard Disk or SSD.
  2. Low cost.
  3. Durable.
  4. Need to serialise as data is stored in file.
  5. Uses BTree for indexing.
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.