Cloud Firestore

You can give ClientDB a try. It simplifies storing data local, and it takes care about syncing it regularly to your remote data storage.

Advantages:

• It's cheap, because you don't have to send a write request to your database every moment. (And it's open source)
• If the user looses internet, it will sync up simply again at the moment he has internet again
• You can implement an instant experience, because you don't have to wait for database feedback e.g. saving data (Not so relevant for your Use case, but maybe overall interesting to know.)

Downside:

• You have an additional layer, that you have to maintain.

I don’t have time to go into a deeper analysis, but consider that with Cloud Firestore projects that I’ve had in the past with heavy write load, my cost was not on the writes: it was in the storage. So maybe consider that in our cost analysis - write over time + storage cost over time. Storage costs tend to be exponential and never go down unless you manually clean up your database. With Cloud Firestore this is harder than with MongoDB atlas, that has TTL for documents. By the way, I’m basing myself over an experience with Firestore from about two years ago, you might wanna check what’s the situation nowadays when it comes to archiving / deleting old data and storage costs. And last but no least, consider both Firestore and DataStore mode in your analysis. I thought there was no advantage for my use case but DataStore mode was actually more suitable at the time for a huge number of writes and deletes.

Also be mindful of performance during writes. I’ve had a bunch of performance issues with FireStore due to heavy write load and had to to batch writes. I would personally chose MongoDB Atlas as I trust MongoDB a tad more as a product, company, and always have the chance to spin up my own Mongo if costs get too high in a cloud platform.

Moving from a SQL database to a noSQL database is a really big deal, congrats 👏! In the current industry having handy knowledge of both is really important and I would recommend continuing to learn Firebase even if it feels a little unnatural.

When using noSQL databases you have consider the idea that the models you work with are individual documents. The data in the documents can be duplicated, re-referenced, and completely dissimilar to each other-the only thing differentiating two documents is an ID value. It's normal for data to be duplicated if you don't perform operations on the same document you already created. You stop unnecessary duplication by wrapping your document creation in a function that checks for a certain value (say if you don't want a username value to appear twice you would check if your collection of documents already has one with a username value and then throw an error).

Creating relations in a noSQL database would be done by referencing a different document in another collection (typically with the aforementioned ID value) and then going and finding that document in that collection. Say you want to find a user's posts. In the User document you would have an array of references to different documents in a Post collection, and then you would go to the Post collection and find each document that has a matching ID number to the ones stored in the User's references.

All in all, you have to realize you are working with two completely different ways of storing and relating data, similar to learning a new and completely different language. If you stick too it and don't try to force SQL onto noSQL then you will get the hang of it and it will be very rewarding.

Postgres is a solid choice over Firestore. The structure of the database schema will definitly help you avoid duplicated data issues. If you want to have an easy to use react integration for postgres, check out Thin Backend

Hi, Akash,

I wouldn't make this decision without lots more information. Cloud Firestore has a much richer metamodel (document-oriented) than Dynamo (key-value), and Dynamo seems to be particularly restrictive. That is why it is so fast. There are many needs in most applications to get lightning access to the members of a set, one set at a time. Dynamo DB is a great choice. But, social media applications generally need to be able to make long traverses across a graph. While you can make almost any metamodel act like another one, with your own custom layers on top of it, or just by writing a lot more code, it's a long way around to do that with simple key-value sets. It's hard enough to traverse across networks of collections in a document-oriented database. So, if you are moving, I think a graph-oriented database like Amazon Neptune, or, if you might want built-in reasoning, Allegro or Ontotext, would take the least programming, which is where the most cost and bugs can be avoided. Also, managed systems are also less costly in terms of people's time and system errors. It's easier to measure the costs of managed systems, so they are often seen as more costly.

Hi, It's depend of which type of data and interaction with database requires, I vote for Cloud firestore as NoSQL Db to store large or complex data. RDS is good for relational data with simple queries. Based on your application functionality you choose the stack. Hope, it helps.

My Recommendations: Front End: Flutter because of developer tooling and powerful declarative widget system Back End: Node.js or Go because Node.js has a large ecosystem and Go has a good built in http setup Database: Cloud Firestore because of ease of use, NoSQL, and the ability to set data from the client

If you go with react / react native I advice you to go with node. Why ? I first didn't believe coding in javaScript everywhere (back, front and db queries) was making life SO much more easy. I still followed the advice, in the end this is a huge relief. For a small startup project with 1/2/3 devs, using only one langage increases efficiency a lot. You can switch very fast from a topic to another.

In the early days, people would set up their own Elastic Search clusters and have troubles maintaining it, keeping it secure, also this required a lot of manual work to get the data in, keep it current, query it... etc. A couple of years ago AWS came up with AWS Elastic Search Service, which reduced some of this overhead. My previous teams and I went through all of these different stages, and ultimately, discovering Algolia a couple of years ago, solved so many of our issues, kept the cost low, reduced dramatically Implementation therefore GTM timelines, and freed up so much of our engineering bandwidth. They have SDKs for most common languages and platforms, and you can achieve a complete solution in just a matter of hours if not minute. Value your own/your team's engineering time. Factor that in when comparing costs. There should also be entry-level tiers you can get a proof of concept rolled out with.

Since SQL Databases have a support for Full Text Search inbuilt into them, they are a better choice. With Firestore you can implement a full text search but it will still cost more reads than it would have otherwise, and also you'll need to enter and index the data in a particular way, So in this approach you can use firebase cloud functions to tokenise and then hash your input text while choosing a linear hash function h(x) that satisfies the following - if x < y < z then h(x) < h (y) < h(z). For tokenisation you can choose some lightweight NLP Libraries in order to keep the cold start time of your function low that can strip unnecessary words from your sentence. Then you can run a query with less than and greater than operator in Firestore. While storing your data also, you'll have to make sure that you hash the text before storing it, and store the plain text also as if you change the plain text the hashed value will also change.