Google Cloud Platform

Since you are already on GCP, why not use their storage service for that? Another option would be to build your cluster with GCP computing instances and MinIO (https://min.io/) or to go with Backblaze (https://www.backblaze.com/). In both cases, you have an S3-compatible API; just with MinIO, you have more things available, like custom policies, hooks, and various integrations. And it is fast. Like very fast.

Really depends on your use case, requirements for access, and level of development effort available for the implementation. EFS is going to be the more turnkey solution with your typical tree based folder/file system within logical volumes. In all my years though, I've never implemented it. Always S3. So rather than to speak about what I don't really know, I'll tell you what I know about S3.

S3 is object based storage. Meaning everything is essentially flat, but you can simulate the usual structure you are used to with virtual folders. It matters not what the contents are and nothing requires even a file extension. Policy contol of files and folders is extremely granular...which is a big plus. Everything should be private and then you manage roles and permissions for access control...or you can use IAM. You can obfuscate everything in your DB in order to put a file name and extention back to an object when you want to serve it up to a user. This further protects your objects even if someone gained bucket access. You can and should make "signed request" links to all files...meaning only for a small window is a file accessible to an intended users. S3 is also infinite. Meaning there is no limit to how much you can persist. While EFS is full scalable in both performance and size it also comes at a cost of elastic compute and storage. In S3, there are also lots of different storage classes meaning standard (hot - accessed frequently) all the way to Glacier (ice cold - archived, basically not accessed). You can also replicate objects to other regions for DR and redudency easily. EFS can be linked using VPC peering as well. S3 also has many useful features like lifecycle management, versioning, and many more. Virus scanning using tags and a Lambda is also an implementation to keep your files safe from harm. S3 also has advanced querying capabilities. Multipart uploads are an essential feature for massive objects (which also basically have no limit). You can chunck the file and send it in pieces for either speed or manageability. S3 can also be used with Glue and Athena to take raw data, assemble it, and then query it with common SQL language. You can also do a similar thing to perform analytics in a AWS Lake.

This is I'm sure not comprehensive, but hopefully helps. S3 will take work to build around, but will give you every opportunity you will ever want. EFS could be a drop in solution that is fast, friendly, and familiar but more costly and with less control.

Considering your expertise in Java and Angular, I recommend a Microservices architecture using Java Spring Boot for the backend. Angular can be utilized for the frontend. AWS is a robust choice for cloud services, and for the database, a combination of SQL (like PostgreSQL) for structured data and NoSQL (like MongoDB) for flexibility in handling unstructured data. For mobile app development, React Native offers a balance of efficiency and cross-platform capability. With a team of 5, this stack ensures scalability, maintainability, and a streamlined development process for your food delivery application.

I think you should use React or svelte and for the backend use Next.js or sveltkit and as for a database I would think you should use mongo DB and if you want to make it cross platform use flutter or React native it would be easy to use both of these if you know React they are very similar to each other and as for Next.js it is a full stack framework which uses React on the front end and nodejs at the back end good luck making the application.

Azure is only ideal if you already use Microsoft products (ASP.net, C#, etc). AWS offers a wide range of services and you get better support ( both at community and enterprise levels). It's not as easy getting help on an issue with GCP as it is with AWS.

AWS is a solid choice. I'd say it's the most popular, meaning there's a wealth of help and how-to guides available. This is crucial when you're just starting in this area. In terms of services, AWS offers a comprehensive range that meets all your needs, especially for beginners. You can also take advantage of the free-tier option for some services, making it easier on your wallet while you're learning the ropes.

Firstly, there's nothing wrong with Firebase for scalability, not can I see anything wrong with "cheap" - unless you expect to need the more complex tools that MongoDB offers (such as Map/Reduce, GridFS and such), I don't think you would want to pay more to get the same capabilities. That being said, there are advantages to move to an open-source code base that you have the option of hosting yourself - preventing vendor lock-in is a legitimate requirement.

Now, as for hosting MongoDB: there are a lot of providers that will host MongoDB (or compatible, see AWS DocumentDB) for you - AWS, Linode or Digital Ocean all offer managed database as a service, so you don't have to mess with VMs and installing and maintaining your own instance of the database server - they are often also cheaper than just running a VM. There's no need to co-locate the database near the application - all of those managed MongoDB services offer great connectivity so unless millisecond latency is critical for your application, any will do.

That being said, your best bet for starting to work with MongoDB is probably MongoDB's own Atlas service - it is a managed service provider that allows you to select in which cloud hosting provider to co-locate a managed MongoDB instance - they support AWS, Azure, GCP and others. They always have the latest and greatest MongoDB version (they make it themselves) and they even have a free tier for starting development on the cheap.

you can also use mongodb atlas, it is a dbaas, it also has shared clusters which are essentially free, good to start with. also are you planning to use an ORM( prisma or mongoose) or raw mongodb driver

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.

Any advise please?

From my past experience, I've used TypeORM and Prisma before and found that Prisma is doing great with CRUD operation, you won't need to code much to save and read the data. And the benefit of Prisma is a single entity definition will do it all. You don't need to define a type, you don't need to define a DTO. Prisma also do t the migration as well. The (little) downsides I found for Prisma were that we need to define every entity in a "single" file, we also cannot do many operations with the queried entity since it's just an object with type, you cannot manipulate it much.

In contrast with Prisma, TypeORM allows you more flexible entity definition and more advanced SQL query (TypeORM has a built-in query builder to build a custom SQL and execute with the database, Prisma has only a "raw" function to execute raw SQL.).

In conclusion, if your application is basically a CRUD operation, with no (or few) complex SQL queries, simple and few entities, I'd recommend Prisma. Its syntax is beautiful, easy-to-use, and will make you develop faster.

I recommend snowflake for even easier setup than bq and better performance. Snowflake can directly connect to Google Cloud Storage and pull data with simple integration: https://docs.snowflake.com/en/user-guide/data-load-snowpipe-auto-gcs.html

for larger scale etl management try dbt and airflow.

I won’t recommend any of those tools if you plan to run thousand of analytical queries each day.

In my opinion you would better use something like Druid or Clickhouse than using bigtable or bigquery

Why ?

• first bigtable is not a database made for analytics. Or maybe you will have a way to format your data so that it can be partitioned and fitted into small rows.

• bigquery has a cost and I would say it is not the right tool for the job, despite being able to handle the load. It will work but given the datasize and the price I would say you don’t need it.

I would better launch a clickhouse install in order to prevent vendor lockdown https://clickhouse-dashboard.cube.dev/how-to-run-click-house