I use Amazon Athena because similar to Google BigQuery , you can store and query data easily. Especially since you can define data schema in the Glue data catalog, there's a central way to define data models.
However, I would not recommend for batch jobs. I typically use this to check intermediary datasets in data engineering workloads. It's good for getting a look and feel of the data along its ETL journey.
We use Quarkus with native compilation in GraalVM for our global REST-API "Charon", that can be used by every developer to request user, server and game-data (protected through OAuth2). Quarkus offers a reliable framework, library and stack for high-quality APIs and integrates Vert.x into its core.
GraalVM pushes the performance boundaries even further with the ability to perform ahead-of-time native compilation so we can reach an incredible small memory-footprint and fast bootup-times that we need for our microservices architecture.
At IT Minds we create customized internal or #B2B web and mobile apps. I have a go to stack that I pitch to our customers consisting of 3 core areas. 1) A data core #backend . 2) A micro #serverless #backend. 3) A user client #frontend.
For the Data Core I create a backend using TypeScript Node.js and with TypeORM connecting to a PostgreSQL Exposing an action based api with Apollo GraphQL
For the micro serverless backend, which purpose is verification for authentication, autorization, logins and the likes. It is created with Next.js api pages. Using MongoDB to store essential information, caching etc.
Finally the frontend is built with React using Next.js , TypeScript and @Apollo. We create the frontend as a PWA and have a AMP landing page by default.
Firebase would be better choice if you want ease of coding and integrating and best performance.As in firebase you can see all the data from front end in Firebase GUI in real time(in Jason format or Document format )But it would cost you as you have to pay google for using firebase data storage .It is highly recommended to use mixture of #realtime Firebase and Cloud Firestore to manage and lower your storage usage budget.
We decided to use MemCachier as our Memcached provider because we were seeing some serious PostgreSQL performance issues with query-heavy pages on the site. We use MemCachier for all Rails caching and pretty aggressively too for the logged out experience (fully cached pages for the most part). We really need to move to Amazon ElastiCache as soon as possible so we can stop paying so much. The only reason we're not moving is because there are some restrictions on the network side due to our main app being hosted on Heroku.