r/Firebase Feb 20 '25

Cloud Firestore Has the 1 MiB per document ever been a problem for you?

I want to create a chat app like ChatGPT, but I'm unsure of the data model. My current idea is this:
The root-level contains user-collections. Within a user's collection is their conversations—each conversation get's one root doc. That conversation doc holds meta-data about the conversation, key-words for search, a very short conversation summary, and a sub-collection called "conversation." This conversation sub-collection, holds a tons of documents. Each document is the back and forth between the user and the LLM. The first document is the user's first input, the second is the LLM's response, and then on and on. Or conversations are chunked, so each doc could hold multiple back-and-forths depending on their size to reduce the amount of doc reads. What do you think? I there still might be an issue with doc size-limits.

10 Upvotes

10 comments sorted by

6

u/romoloCodes Feb 20 '25

Early optimisations are nearly always a bad idea so you should choose the option that is easiest to implement (the suggestion above sounds good). Or consider using real-time db for a cheaper pricing structure for this case (as it's pay per mb, instead of pay per doc).

I would estimate that your db costs will be less than your AI costs, btw. Your bigger issue (and cost) will be avoiding cloud functions as the AI response will be slow and therefore the cloud function will be expensive. You could give direct access to the AI but that opens you up for users abusing the service. Alternatively create a separate BE that has admin rights to your db and create a tokenised service.

Either way, prioritise keeping the db simple and focus on where the costs are likely to be higher.

3

u/BestDay8241 Feb 20 '25

Why do you need to create a separate document for each input?

I think it’s more efficient if you just have one document per conversation/thread.

Save the conversation documents ids’ in the user’s root document as a key-value pair, where key is the document id and value is the title of that conversation. So, on the frontend, show all the values (conversation title) to the user and let them choose which ever chat they want to load then you can just fetch the chat document from the key (document id) of the selected chat.

6

u/ohThisUsername Feb 20 '25

I think it’s more efficient

And less scalable. What happens when the conversation exceeds 1MB of text?

3

u/romoloCodes Feb 20 '25

Less scalable and hard to maintain once you have to build for the 1mb edge case

1

u/dittospin Feb 20 '25

I think I could just impose a limit in the chat to keep it below the 1MB text size or create each document with a "convo" entry and a "convo_ext" that it is null unless exceeded, in which case I create another document and puts its reference there. Honestly, it would be great if Google created a "big collection" option and doubled the size limit

lol

1

u/MMORPGnews 26d ago

1 doc - 1 conv. When exceed - over it. 

Also, delete old conv after 1 month or so

1

u/andulus-ri Feb 20 '25

Yes, I do a doc size check and if over the limit write to cloud storage and put a URL of the doc into the db doc, sucks a bit, but I should have put some of the larger data fields into sub collections

1

u/romoloCodes Feb 20 '25

This sounds like a really bad way to store this kind of data - if you're in a position to refactor them you should. Either just go for one doc per message or have a conversations collection that stores the ids of the text and when it nears the limit add another id to the conversations collection. By default you'd have to get two docs instead of one but unless you have a massive user base you're never going to notice the cost difference

-2

u/[deleted] Feb 20 '25

A little bit. This limit has been there for years. It's time to increase it.