> No, the database should not be the answer to all your data problems. Yes a microservice may be the best answer.
Or to put it another way: No, microservices should not be the answer to all your data problems. Yes, using the DB may be the best answer.
In one case it might just be slow. In the other your db will fall over. Unfortunately, you may find the answer when your production environment fails.
If you have a single DB instance in production, something has already gone wrong.
Read replicas.
> Recently someone started appending to a json field type over and over in our production database. And then on some queries, postgres crashed due to lack of memory. The fix was to remove the field and code that constantly appended to it, and do something else.
So your choices are doing something manifestly non-optimal in the database in violation of best practices or not use the database for non-trivial business logic?
Sounds like a false dichotomy to me. Maybe just find a better solution?
I mean, if someone writes an O(n^3) algorithm in Python, is the solution to use a better strategy or to swear off Python for anything non-trivial?
This works until your database falls over in production. Recently someone started appending to a json field type over and over in our production database. And then on some queries, postgres crashed due to lack of memory. The fix was to remove the field and code that constantly appended to it, and do something else.
No, the database should not be the answer to all your data problems. Yes a microservice may be the best answer. But for structured data and queries that can run with normal amounts of memory the standard SQL DB is fine.