Very few organizations in the world truly need to scale out their database. Their problem is usually that of a bad design. For those that need to scale out, NoSQL is not a magic solution either. The scaling out solution pretty much these days for SQL database is replication, sharding and partitioning tables. Postgres does these very well.
> The scaling out solution pretty much these days for SQL database is replication, sharding and partitioning tables. Postgres does these very well.
I tend to disagree that Postgres does partitioning well; partioning table resolution is rather dumb, there is no hinting (e.g. there is no way to tell postgres that there is a unique mapping for each query to a table) and no caching of CHECK results.
> Very few organizations in the world truly need to scale out their database.
Everyone organization that has a database wants to scale out to at least a 2 node cluster just for not having a single point of failure. Scaling is not always about performance, at first, it's more about availability.
Almost every major organisation will have a big data analytics program doing feature extraction, modelling, machine learning etc. Usually this starts with Hadoop/Spark with data in HDFS but then a point comes when you want this in a database.
PostgreSQL is awful at this which is why almost no uses it in this space. Apart from the lack of native drivers it is simply too difficult to do basic clustering. And the fact that it isn't built into the product doesn't give you a lot of confidence that it is (a) going to work and (b) is going to be supported.
And yes for those that scale out NoSQL is a magic solution. That's why they are so popular. I can deploy a 40 node Cassandra cluster in 30 mins and guarantee it works. Likewise MongoDB replica sets are ridiculously easy.
Well, we ran a billion queries per day on a 1.4TB system I was in charge of a couple years ago. Now we're building a 500+TB reporting system and probably putting it on Postgres-XL. Seems to scale fine to me. ;)
Only loosely in so far as bad performance can make scaling more important; however, scaling is not about performance, a super fast db could scale poorly while one that scales well could perform worse than the fast one but scale better. Scaling is about growing across machine boundaries well, so that adding more machines increases the ability to handle more load. That doesn't require good performance, it's requires good architecture.
Agreed. Scaling out databases is never something you want to do, particularly for Postgres.
But it's something you're less likely to need if you structure your data, in an RDBMS. If you know your SQL, then optimizations should be preferred before scaling out. Not just because you need to, but because it can improve user experience (server response latency).
Well Django is good for ORM, migration and admin. DRF gave a new opportunity to provide new web technology to this old framework but it's not enough.
The global stack is very heavy and it's very complicated to use Websocket.
I was fan of Django but for me the future is in framework like phienix: light stack, fast, secured and supporting current web technology. It's avoid you all the time loose to implement tornado/rabbitmq stuff.
