For a couple similar use-cases (write rarely, read many times, JSON data) I ended up using actual JSON files, on disk. Time to read and parse them is very small compared to asking Redis or PG for it, and this benefits from the Linux disk cache, which makes reading from those most-unchanged files almost the same as reading it from memory.
How much faster is Redis at storing a blob of JSON compared to Postgres?
81–90 of 119 posts
Re: How much faster is Redis at storing a blob of JSON compared to Postgres?
#82Earlier quoted context omitted.
Looking up a row of JSONB data by a primary key in a 3GB PostgreSQL table on my laptop takes 0.4-0.5ms, since it easily fits in memory and Postgres caches the data.
If it fits in RAM, you might as well put it in memcached. You will likely get a 10X speedup. EDIT: To be fair, RAM is cheap these days, and most real world projects fit into RAM without a crazy budget.
Ram is cheap everywhere but "cloud" instances. Was just noticing the other day, I can get about 128GB of ram on a dedicated instance for the same price I am paying in the cloud for 16GB.
Re: How much faster is Redis at storing a blob of JSON compared to Postgres?
#83Earlier quoted context omitted.
I found the thinking in the article to be mushy. The title asks a reasonably specific question, but the article then goes on to talk about things in ill-defined ways. It mixes in other layers which aren't directly part of the titular question, but nonetheless influence the answer. In an update, the author goes so far as to state that a new test done differently resulted in a different answer. As you point out... very…
> The article is just anecdote, not really good testing. Mayhaps. Or, just a snapshot from the trenches of real application development. We all have to make choices. Different pros and cons. Before jumping into, perhaps run some tests with real stuff and change direction based on that. In application development is usually doesn't matter what the core difference is between two databases because there are drivers and…
Normally, I would agree that it's a snapshot or data point. But one of the things that I don't see mentioned anywhere else is that this is running on a macbook. I don't know how it works with his setup, but I get significantly different performance results on my local dev system (windows) than a linux server.
I run everything in hyper-v docker, which should actually get pretty close to bare-metal performance (as hyper-v sort of runs an instance alongside windows, rather than virtualized on top).
However, due to some quirkyness, maybe something with docker networking, I rarely get very good performance and I assume in this case, they are either using ported versions of the software or also running virtualized.
So I'm not sure if these kind of benchmarks add data points to anything but "performance on a dev machine".
Re: How much faster is Redis at storing a blob of JSON compared to Postgres?
#84Earlier quoted context omitted.
> but I think there are plenty of cases where you could use it without fear that your data will evaporate. What about "redis-cli flushall"? (Don't type this on your production cluster).
What about 'drop database' for Postgres?
> access denied
ACLs in postgres are powerful and valuable and something that redis lacks.
Re: How much faster is Redis at storing a blob of JSON compared to Postgres?
#85Earlier quoted context omitted.
Looking up a row of JSONB data by a primary key in a 3GB PostgreSQL table on my laptop takes 0.4-0.5ms, since it easily fits in memory and Postgres caches the data.
If it fits in RAM, you might as well put it in memcached. You will likely get a 10X speedup. EDIT: To be fair, RAM is cheap these days, and most real world projects fit into RAM without a crazy budget.
Why even memcached? It's not going to be 10x faster than your typical LRU cache (e.g. Postgres' shared buffers). It might scale a little better, but you should only consider that when it's worth it.
Re: How much faster is Redis at storing a blob of JSON compared to Postgres?
#86This is cute.
Re: How much faster is Redis at storing a blob of JSON compared to Postgres?
#87postgresql does TOAST compression of large jsonb blocks. You might be incurring the cost of compression/decompression by postgresql
Uh...TOAST is a system for storing data off page. It doesn't have anything to do with compression? Reading a TOAST actually requires reading two pages, so you're correct that there is read and write overhead. But it isn't CPU bound a la compressing the data.
Re: How much faster is Redis at storing a blob of JSON compared to Postgres?
#88Hey, Original blog post author here. What a lot of people don't understand is that you want it both. The resilience of Postgres and the speed of fetching from Redis. You have data stored. You want to retrieve it as painlessly (shorter time, less CPU usage, less complexity, etc.) as possible. What are the options? How much faster is Redis? How much RAM is that going to eat up? Different tools have different properties…
> What a lot of people don't understand is that you want it both.
Of course I want both. I also want a car that requires zero fuel, can go super fast, has great safety features, and is less than $100. Life is about trade offs and you have to make them for specific reasons.
People trade off using Redis vs Postgres for different workloads intentionally. They aren't meant to be used for the same workloads and are _not_ interchangeable.
Your comparison (and article) is worthless and, in fact, hurts more than it helps.
Re: How much faster is Redis at storing a blob of JSON compared to Postgres?
#89A good read, but wouldn't count these results as anywhere near valid - if you're using an ORM, you're just perf testing the ORM.
> anywhere near valid
Yeah they're laughably naïve.
Re: How much faster is Redis at storing a blob of JSON compared to Postgres?
#90Why can't Postgres implement a transparent caching layer similar to Redis?
> Why can't Postgres implement a transparent caching layer similar to Redis?
Bruh it does! That's what page pools are all about. Not to mention the query cache...