Every project is different, everybody has different needs, and so on. Yet I have been using this stack for practically 10 years and always found that it was easy and straightforward to use for the dozens of apps I built in the meantime:

• PostgreSQL.
  • It has so many features. It's just unbelievable what it can do.
  • And you know, everything works and makes sense. Time zones are a perfect example of that, the design is very clean especially in comparison to other engines that just ignore the problem one way or the other (MySQL I'm looking at you).
  • Also for NoSQL fans, it supports indexing JSON and making queries on JSON so basically you can mix "NoSQL" with SQL super-easily.
• Django
  • Its ORM has the nicest migrations system out there
  • The migrations system is awesome
  • Also thanks to the ORM the migrations are perfect
  • CRUD admin is automatic
  • REST API is almost automatic with DRF
  • On the contrary to every other stack I've used (various PHP frameworks) it never slowed me down
• Redis
  • Dumbfuck simple
  • Perfect to share state between servers

Imaintain my own. I discovered the project about two hours out from giving up on the state of relational data access with Node and rolling my own framework. I've been using it for something like four years at this point, and not quite two years ago, the original developer moved on and I took over the project.

Two points to the elevator pitch:

• Massive is a data mapper, not an object/relational mapper. O/R mapping is by far the more common data access technique, but its emphasis on convenience for application developers comes at a heavy price everyone eventually regrets having to pay: inflexibility, limited access to database features, and a host of bad database design habits. Data architecture is worth doing right, and Massive starts you off with an approachable API that lets you get the most out of your database from the word go. It's a much more flexible and sustainable foundation to build off of compared to the O/RM approach of trying to shoehorn a relational data model into an object graph and vice versa.
• Massive is laser-focused on PostgreSQL. There's so much that Postgres has to offer above and beyond its competitors that ignoring it for the lowest common denominator feature set makes little sense unless there's a compelling business reason to support multiple relational database platforms (really, you could say this for almost any RDBMS; nobody complains about vendor lock-in with MongoDB or Cassandra!).

Imaginate server which supersede even outperforms all moving parts of your backend stack like NoSQL database, graph database, search server, cache server and application server.
Imagine how much pain caused by integrations you could avoid and how much time needed to learn, set and maintain all moving parts of your stack you could save by having one stop shop highly available and scaleable solution where Javascript rules to all.
Then give a shot toArangoDB and make your dreams come true.

Stack

ArangoDB - highly available Multi-Model NoSQL database with integrated JS framework powered by Google’s™ V8

• we're Typescript/Javascript based, so ArangoDB as document store with integrated Foxx for microservices is perfect fit
• graph and AQL are hidden gems, especially from relational database perspective, once understood and grasped, then it turns literally into preaching graph databases over relational for a lot of use cases
• similar it's with microservices concept, once we did find out, how seamplessly Foxx adopts middlewares and jobs, then cases like authorization of user down to attributes of document, scheduling and batching tasks, connecting to 3rd party services became piece of cake

Node-RED - flow-based programming for the Internet of Things

• no code rapid prototyping,
• integrations with 3rd party APIs,
• ETL utilizingJSONata

For our current project we are using a C# WebApi backend, which connects to a MySQL database hosted on RDS and AWS Athena for the big data part. The MySQL part is handled through nHibernate, but I'm personally not happy with this framework and would rather see it replaced by something a little more lightweight and easier to use. As for AWS Athena, I tend to think the cloud services pitch themselves. We had to search for a scalable and affordable big data solution and AWS Athena came out as a winner. It is really fast on the queries we are running, easy to update and cheaper then any other solution.

Depends, but my favorite stack is

Slim 3 -the fastest framework for PHP atm

Vue.js -which needs no introduction ATM but a couple of months ago it was a risky decision

nginx -the best server for doing weird things, glorious config

MariaDB -the standard db

PHPUnit and xDebug for backend testing and analisys.

I also enjoy developing plugins with thePHP-CPP library. Once, I wrote a web enabled face matcher based on dlib and hosted it via a plugin.

Other than that, composer, npm. Deploying the frontend via CDN and reverse proxy, backend usually on specific subdomain. Clean cut between front and backend.

Recent deliberations involve going redis and NoSQL, CI/Testing automation. Otherwise, this stack works swell, it's easy to onboard new developers and gets results fast once the simple patterns are understood.

Depends on the client.

Lately: Flask/Django/Python or Go (framework less) or Rails/Ruby

The common denominator is PostgreSQL. I use Redis as well.

I don't like Django that much, in a specific case it was his admin framework to be a factor in the choice.

In the future I don't know: I hope more Flask/Python and Go :D

Elevator pitch for Flask:

it's super simple but it can scale to big apps thanks to composable apps. It mostly gets out of your way: you can decide to use an ORM or not, it doesn't care (data mappers are appreciated). It's not the fastest ever but you already know that most of your issues are I/O related, don't you? :D

My typical toolbelt includes Rails and Node for the backend. For sites with tighter deadlines, lower performance restrictions, or less interactive frontends, I usually reach for a vanilla Rails backend w/ Postgres + Heroku. For more involved web apps, Node is usually my choice and nowadays I might also consider a GraphQL server powered by Apollo Server.

Elixir/Erlang for the backend apps. I usually use Phoenix framework for the web/http part.

Postgresql as database. It also has JSONB support when I need to store data that I don't need to query too much.

Redis/Mongo for storing not-so-important stuff (eg: caching data or events). Sometimes I rely on Erlang's ETS (in memory, concurrent, built-in key-value store) instead of Redis.

Nginx as http server and/or reverse proxy.

When I can chose, I always go for FreeBSD as server OS. I don't like Linux anymore (at least since systemd). It's easy to use, very well documented (official Handbook and well crafted man pages), stable. When I need isolation/container-like stuff, I use FreeBSD Jails (a sort of builtin LXC, the foundation for docker).

Ansible for server provisioning.

Rails on Heroku, with Postgres and Redis. I work alone rather than as part of a team, and the convenience and productivity of these tools is phenomenal under those circumstances. The Rails team has done a great job keeping the framework up-to-date too, making it both well-established and continually improving. It hands you a lot of configuration by default, including important security options. Abstracting away virtually all ops concerns via Heroku has been invaluable to me.

Rails is opinionated, so the biggest reason not to use it is if your opinions differ from those it is based on. Additionally, if you are a fan of static typing over dynamic, you will hate it. If you're concerned about memory usage, you will hate it. If you rely on a compiler to find errors for you, you will hate it. Rails lets you build your app fast, but that means you build up technical debt just as fast if you are not disciplined as you go.

As for Heroku, the biggest reason not to use it is that the shared infrastructure leads to variable performance. My response times and memory usage vary from day-to-day. This is an issue that isn't unique to Heroku, but more a byproduct of shared cloud infrastructure. Heroku also restarts all dynos once a day, so if you rely on long-running processes or have long startup times it might not be a great fit.

I've been using ASP.NET Core for the backend for the past three years. I've coupled that with PostgreSQL DB and it's worked perfectly. I'm migrating to Microsoft SQL server because that's what I'll have available in next environment.

Also, currently been playing with RabbitMQ and MassTransit service bus to transfer messages between services.

ASP.NET Core is fast, open source, cross-platform, and comes with great documentation and community.