What is it with Postgres fans that "have to" prove they're better?
I don't want to use Postgres. I want to use Redis. Postgres IS NOT the solution for a lot of things. Yeah, feel free to call me stupid for not knowing every nook and cranny of PGSQL. I don't care
"I love to argue, but this is just a futile exercise."
Well Redis is NOT the solution for many things too. I find it is a huge problem in the DB community that people think there has to be a solve all solution. Every DB strategy has strengths and weaknesses. I use Redis and Postgres they are both excellent products. I think the days of having a single data-store are gone. I personally use different data stores depending on the type of data I am dealing with. It is like the old interview question "What platform does Google use?"
I've actually been following the "Twitter drama" around antirez, redis and everyone else - and it has little to do with "Postgres being better" and every complaining with Distrubuted Redis (Redis Sentinel/Cluster?) being terrible.
AFAIK, the arguing with Antirez with Redis has been going on for weeks now (and it hasn't been necessarily been unfounded). The exact issue the Stripe guys had, had to do with a replicated Redis setup.
There is nothing specific to replication in the Stripe issue. They noticed a well-known problem which is that, with large datasets and some categories of hardware, forking to snapshot to RDB takes a long time (can be a few seconds) and blocks the Redis process. This also happens on single-instance Redis.
EDIT: actually I am talking about the second problem mentioned in their post here: https://stripe.com/blog/game-day-exercises-at-stripe (latency spikes). The first problem (data loss) is related to replication.
I can't speak to Redis, because I don't use it, and mostly see it as being fairly distinct from Postgres, but with Mysql it's always frustrating to know that you could be using a tool that's generally better, but can't, because initially someone chose Mysql because they "heard it was fast" or "that's what the hosting company provided", and now they're stuck with it.
You are not wedded to an SQL vendor. You actually can migrate your data, as long as your code is farily vendor-agnostic. I write Django apps and use the ORM for everything. That frees my customers from any sort of raw sql specific to one DB server.
If everything you do is CRUD, sure. Often there are non-CRUD, more advanced queries that need to be run. These, and other issues, are normally what gets you. For instance, pgsql will error if you attempt to write 5 chars to a 2 chat field, mysql will silently truncate.
I'm trying for the life of me to think of queries I could make that are non-CRUD. Maybe I am just stuck in my current tools to think flexibly about it.
I presided of over a Migration from DB2 to Oracle. All of the operations were CRUD.
However the DB2 database had materialized views that were crucial to the business.
Porting those over was non-trivial. Oracle returned a different value for null fields than DB2 (empty strings for null strings vs actual null in one case) did so various portions of the code would fail seemingly randomly.
Some of the constraints didn't map quite as cleanly as the others.
And we haven't even started on the performance tuning and how your schema affects them.
Sure you may be able to port all or most of your schema and queries over to another database but you'll have a lot of work to do after that verifying that nothing is broken and your performance is still acceptable.
SQL is not even close to a guarantee of portability.
Using CTEs, including writable CTEs is not something I'd want to do in an ORM. Also, whenever I find myself having to have more than a few expression fields, I find ORMS clunky.
Trying to load more than one record from a a single row is supported in some, but not all ORMs as well.
Aggregate queries, especially more advanced ones than just min, max, sum, avg, stddev, &c, are not always supported by ORMs either, or you need to use expressions or extend parts of the ORM. It's just a mess sometimes and I'd rather query and then load.
It always annoys me to hear people talking about how slow MySQL is and have to deal with them going about modelling things poorly and sweating a few million row when they don't know how to design indexes properly and don't understand predicate order.. Or correlated sub-queries.
That said, PostgreSQL is pretty fantastic software too.
I've been friends with antirez a lot longer than Redis has been around, and have a lot of faith in his abilities as a programmer. It irritates me to see the snark directed at him on Twitter.
But for most of what I do - smallish bootstrapped things - I want to build on Postgres, because I know I can take it a lot of different directions, as needs be. Unless I'm 100% sure that it's a bad fit for SQL and a great fit for Redis or something else, I'm going to consider Redis as a later optimization, not something to build on from the start.
Like you write though, I mostly view Postgres and Redis as Apples and Oranges that could probably work together quite well in the right circumstances. Most of my ire is directed towards Mysql :-)
Moreover, I can't remember a single time PostgreSQL folks have been unfair... PostgreSQL is definitely good both as a product and as developers culture.
This is a perfect example of the problem the guy you're responding to is talking about.
You are correct, but nobody chooses databases by count-of-good-use-cases. You choose databases by applicability against the use cases you have in front of you and are likely to have in front of you.
I don't want to use Postgres. I want to use Redis. Postgres IS NOT the solution for a lot of things. Yeah, feel free to call me stupid for not knowing every nook and cranny of PGSQL. I don't care
"I love to argue, but this is just a futile exercise."
Very wise words