Firebase Blog

You should try to not start a comment with an attack. It just makes you look bad. See: http://www.paulgraham.com/disagree.html

Regarding your points:

> 1. ORMs are slow

Maybe you haven't used any recent ORM. Where did you get this idea from? In the JVM world, Hibernate is nearly dead for new projects. EBean[1] and JOOQ[2] are both great choice server-side Java/Kotlin/Scala projects. On Android / for SQLite, there's DBFlow[3], which I've used, and had great experiences. These ORMs are fast, intuitive, and powerful.

Also relevant is: https://dzone.com/articles/martin-fowler-orm-hate

> 2. Mongo supports relationships

Mongo's approach to relations[4] is far weaker and less powerful than what an RDBMS can handle. It was almost tacked on later as an afterthought. In addition, joins aren't a easy and straightforward with the kind of relations that NoSQL databases, like MongoDB support.

> 3/4. Lack of normalization and schema is only a problem if you let it be. This is why model layers exist!

NoSQL databases actively encourage de-normalization. For example, just take a look at this Firebase blog post[A] or see this page in their documentation[B]. It's almost sad and a shame that a company like Google is encouraging such poor ideas and practices; practices that they likely don't follow themselves (but I could be wrong).

I know some young devs, who just graduating out of college, swoon all over databases like Firebase's. They read articles like these that say "schema-free" is…

There's so many red flags in this article I'm not sure what I can really take away from it.

> These things may still be "hacked" using Firebase, but it means that you will have to add even more code to your web-app, and it could be a nightmare to maintain if you have a mobile app too.

So don't hack it and don't repeat it. Do it once on your server.

> You may query directly Firebase over the network, right from your backend, but you should avoid doing this because it is really slow at scale.

So queries from a browser and mobile client are more performant than a server running in Google's own datacenter? I'm guessing they're running queries that don't fit Firebase. It's a key/value store with a single simple query mechanism. The awesome feature is that it will solve the data synchronization problem. On the forums and stackoverflow, the Firebase team is quick to point people to using a server process to keep things simple.

> dealing with relations with Firebase is pain in the ass.

Why are you using a key/value store?

> it's not possible to export your users data

Are the Firebase docs lying to me? https://firebase.googleblog.com/2015/03/private-backups-for-firebase-data_21.html

> Complex queries are impossible

It's a key/value store...

> Want to build an API for your product? It's impossible.

WTF?

> old-fashioned SQL Database, which overs 90% of our data storage needs... For the 10% part, we decided to use MongoDB to store messages and conversations at scale.

So…

Firebase engineer here. I hope you've been in touch with our support team and I'm sorry to see you've had so much trouble. You point out some genuine limitations with our product. We have some great improvements in the pipeline and I'm sorry that they came too late for you. In case others have had similar experience, it's worth mentioning that some of these seem fixable by structuring your data differently[1].

Specifically, complaints 2-4 sound like they all arose from nesting all of your data in one tree[1] and using a query for all children[2]. This means you'll load too much data in every request, which will slow down your microservices and cause a large bill for unnecessary outbound traffic.

#5 has two possible solutions. Either use the push() message to avoid any conflicts in the data you're writing or the transaction() method to manage the conflicts in an online-only mode. push() requires some work to recompose something from a series of changes, but has the advantage of being offline-compatible.

Regarding #6, I agree we can better support data migrations (we're looking into it). If your problem is as simple as the one listed, I'd really recommend checking out a library like lodash[3]. The ugly if statement could have been

if(_.has(user, 'new_subdocument.new_property')) {
/* do stuff */
}

or even:

var thing = _.get(user, 'new_subdocument.new_property', default);
// always do something with thing; we just added an in-memory
// value that we would have made a…

[Firebase founder] To offer better querying, improve the data model, and increase scalability we had to build an entirely new database. The original technical choices we made as a startup weren't able to support the featureset Cloud Firestore has. Even if we tried to improve upon the existing Realtime Database product, we would have had to make breaking changes that would have required you to rewrite your code (and likely shipped a worse product).

Regarding deprecation: you can be comfortable continuing to build on the Realtime Database. We don't intend to deprecate either database, since both are useful in different situations, depending on what you're building. We recommend using the Realtime Database for a number of usecases[1]

We're not posting a "Realtime Database will be supported for X years" statement because many may interpret this as "the Realtime Database is deprecating in X years", which isn't the case.

[1] https://firebase.googleblog.com/2017/10/cloud-firestore-for-rtdb-developers.html

(firebase founder here) I’m thrilled to finally be able to show everyone what we’ve been working on over the last 18 months! When I said “big things are coming” in the HN comments back when our acquisition was announced, I was talking about today : )

We’re really excited about these new products. There are some big advances on the development side, with a new storage solution, integrated push messaging, remote configuration, updates to auth, etc. Perhaps more important though are the new solutions for later in your app’s lifecycle. We’ve added analytics, crash reporting, dynamic linking, and a bunch more so that we can continue to support you after you’ve built and launched your app too.

I'd suggest reading the blog post for more info:
https://firebase.googleblog.com/2016/05/firebase-expands-to-become-unified-app-platform.html

This is the first cut of a lot of new features, and we’re eager to hear what the Hacker News community thinks. I look forward to your comments!

See also Firebase push IDs:

https://firebase.googleblog.com/2015/02/the-2120-ways-to-ensure-unique_68.html

Lexicographically sortable identifiers are critical for any distributed data store if you want anything close to consistency. I've run into the issue of not having them and having to settle for some kind of <autoincrement_id><UUID> key and it's a huge PITA. How this wasn't considered database 101 decades ago just blows my mind.

I'd like to see a spec included in this for synchronizing clocks or using RAFT/Paxos for generating ULIDs with strong guarantees on sort order.

Also a minor gripe - I wish that the ULID spec checked for microsecond collisions instead of millisecond, because that would be more useful for realtime networked gaming and simulations.