按客户细分Mongo / Postgres数据库的正确策略？

Question

I'm building a web app (python/Django) where customers create an account, each customer creates/adds as many locations as they want and a separate server generates large amounts of data for each location several times a day.

For example:

User A -> [locationA, locationB] User B -> [locationC, locationD, locationE]

Where each location is an object that includes name, address, etc.

Every 3 hours a separate server gathers data from various sources like weather, check-ins etc for each location and I need to store each item from each iteration so I can then perform per-user-per-location queries.

Eg “all the checkins in the last week group by location for User A”

Right now I am using MongoDB and storing a collection of venues with a field of ownerId which is the ObjectID of the owning user.

What is the best strategy to store the records of data? The naïve approach seems to be a collection for checkins, a collection for weather records etc and each document would have a “location” field. But this seems to have both performance and security problems (all the access logic would be in web app code).

Would it be better to have a completely separate DB for each user? Are there better ways?

Is a different strategy better if we switch to Postgres/SQL database?

Answer 1

[GENERAL ADVICE]: I always use Postgres or MySQL as the django ORM connection and then Mongo or DynamoDB for analytics. You can say that it creates unnecessary complexity because that is true, but for us that abstraction makes it easier to separate out teams too. You have your front end devs, backend/ full stacks, and true backend devs. Not all of them need to be Django experts.

[SPECIFIC ADVICE]: This sounds to me like you should just get started with mongo. Unless you are a B2B SaaS app selling to enterprise companies who won't like a multi-tenet data model then it shouldn't be tough to map this out in mongo. The main reason I say mongo is nice is because it sounds like you don't fully know the schema of what you'll collect ahead of time. Later you can refactor once you get a better handle of what data you collect. Expect to refactor and just get the thing working.