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