Dovrei usare Firebase/Firestore per una grande app con più di 100.000 utenti?

Prima di tutto, quando si parla di database nella suite Firebase, parlerò solo di Firestore, e non di RTDB (Realtime Database, che tradizionalmente era conosciuto solo come Firebase). Firebase ora si riferisce ad un'intera suite di servizi, che include Firestore, RTDB, archiviazione di file, autenticazione, ecc. RTDB sarà probabilmente eliminato e Google sta chiaramente mettendo i suoi sforzi dietro Firestore.

In secondo luogo, non c'è sharding manuale in Firestore, come c'era in RTDB. Lo sharding è gestito automaticamente da Firestore, quindi ignora le altre risposte su questo.

Terzo, tu, il cliente, possiedi i dati nel tuo database Firestore, non Google, quindi ignora anche le altre risposte su questo. Se Google, e non il cliente, possedesse quei dati, Firebase non avrebbe praticamente nessun utente. E, sempre contrariamente alle altre risposte, è possibile esportare i dati da Firestore. Se i clienti non potessero esportare i loro dati, chi mai lo userebbe?

Quarto, il suggerimento di usare la tecnologia SQL sui propri server fisici (quelli che si possiedono fisicamente) non è qualcosa che penso appartenga ad una risposta a questa domanda. SQL vs NoSQL e cloud vs in-house sono decisioni che dovresti aver già preso se stai chiedendo di uno specifico provider serverless. Chiaramente (almeno apparentemente), hai deciso su serverless NoSQL, che è sicuramente la scelta più popolare oggi. E tra i due provider più popolari, AWS e Firebase, sono progettati per gestire praticamente qualsiasi carico di lavoro che gli getti addosso. Le applicazioni più trafficate al mondo girano su NoSQL serverless, come il marketplace di Amazon, per esempio (AWS, ovviamente). Se AWS può gestirlo, anche Firebase può farlo. Google non progetterebbe mai il suo NoSQL serverless per raggiungere il massimo ad un certo numero di utenti o livello di traffico; è progettato per scalare virtualmente all'infinito.

L'unico avvertimento a Firestore (e NoSQL serverless in generale, in realtà) è il costo in dollari, per ora nel 2019, comunque. Firestore era considerevolmente più costoso solo un anno fa di quanto lo sia oggi, pensateci. Penso che NoSQL serverless continuerà senza dubbio a diventare più economico, compreso Firestore. Ma, in questo momento, con una base di utenti relativamente grande, NoSQL serverless, come Firestore, può diventare costoso. Ma anche fare tutto in-house. Una soluzione in-house ha ancora un costo di larghezza di banda, oltre all'hardware e al costo umano. Assumere ingegneri backend qualificati per costruire e mantenere una configurazione in-house non è economico (centinaia di migliaia di dollari all'anno). Firestore (e DynamoDB) hanno eccellenti calcolatori di prezzo per aiutarvi a prevedere i vostri costi e potreste essere sorpresi di vedere quanto sia economico con una base di utenti di modeste dimensioni, anche con 100k utenti.