14

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?

Frank van Puffelen
  • 418,229
  • 62
  • 649
  • 645
Magnus W
  • 11,902
  • 10
  • 61
  • 135
  • 10
    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. – CodeCaster Apr 15 '17 at 09: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... – Magnus W Apr 15 '17 at 09:36
  • I think the naming aspect would be it, but I'm not certain (otherwise I'd have posted it as an answer). – CodeCaster Apr 15 '17 at 09:41
  • 1
    A further source of confusion was that [Wikipedia](https://en.wikipedia.org/wiki/Real-time_database#Overview) 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? – Magnus W Apr 15 '17 at 10:05
  • 1
    Also, if the server supports HTTP long polling, isn't that effectively the same thing? – Magnus W Apr 15 '17 at 10:39
  • 1
    BadCash: Firebase uses Web Sockets when available and falls back to long polling when sockets are not available (an infrequent occurrence these days). Arguing against the name someone picked for their product more than five years ago is unlikely to be fruitful and thus off-topic on Stack Overflow. @CodeCaster please post an answer, since you pretty much got the gist of it in your first comment. – Frank van Puffelen Apr 15 '17 at 14:24
  • 1
    @FrankvanPuffelen I'm simply explaining why I'm asking the question. If you never heard the term "realtime database" before, Google it, find Firebase and Wikipedia, I bet you'd be confused as well. And I'm still confused about what makes Firebase a "realtime database", but some other backend database that supports long polling just "a database"...? Or are you telling me that "realtime database" is just a part of the product name, and not really a concept like for example "cloud messaging" or "backend-as-a-service"? – Magnus W Apr 15 '17 at 15:28
  • 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. – Frank van Puffelen Apr 15 '17 at 15:39
  • Backendless database has the real-time quality (https://backendless.com/features/backendless-core/real-time-data/) meaning any time you create/update/delete data all connected clients that subscribed to receive updates will receive a message about the change. The message is pushed to the client-side, no polling is required. – Mark Piller Oct 14 '19 at 21:32

2 Answers2

2

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.

Santosh Kadam
  • 972
  • 9
  • 11
1

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.
Bharathkumar V
  • 166
  • 3
  • 12