Not exactly true. There are things like "Redis on Flash" that redis.com offers for large sets of data. If you enable it, most of your data gets stored in a Flash memory and hence super cheap, in fact even cheaper than things like DynamoDB and stuff.
Remember, many of these things that get released are usually just vaporware. They may become better 6 months or a year later, or, they may never see the light of day.
Introducing Redis Launchpad! . A central place for quality sample apps that use Redis as a realtime platform and a primary database. Explore architecture, data modeling, commands, and more.
Amplitude is NOT a great product when you actually try to implement it. I have seen at least 3 companies pay for them based on how good it looks and all the promises but only to realize that the integration is actually very hard, and the data in Amplitude is often wrong! Also they dont do a good job in sending data back to things like SFDC and what not.
I used to help answer customer support questions with Amplitude. Sometimes what looks like incorrect data is just that the query is different from what you’d expect. Something like “has a user been retained?” is a complicated question and has a very specific definition that may not be surfaced in the UI entirely, yet varies from analytics product to product.
The result is sometimes the data seems to be wrong (inconsistent with other products) when really the problem is a lack of industry standardization on the different definitions of terms.
Completely agree about the Object-relational mismatch. The general term "Impedance Mismatch" is used in several industries to mean the loss in efficiency due to increase in complexity.
"Object-Relational Impedance Mismatch"[1] is been around for decades. Martin Fowler[2] and others who are deeply technical (think Sr. architects, CTOs) use this all the time.
Good question. Redis Timeseries is just a different data structure and works alongside other data structures so it wont add too much Impedance when compared to having different data in different systems.
On the other hand, imagine you used Redis for just cache and used TimescaleDB instead. TimescaleDB is based on PostgreSQL, so you need to use a different thought process, different SDK, different commands (SQL), different hosting, different devOps, etc. And for performance purposes, say stored some data in Redis for caching, now you have additional overhead because you need to now manage data in two systems. And let's say TimeScaleDB needs some other adopters to sync the data to Kafka, and Kafka needs Zookeeper, now all of a sudden you have 4-5 systems.
The goal of the Impedance impedance mismatch test is to identify such scenarios using a simple calculator and avoid them. In 2021, there are many single systems like Kafka, Redis, Cosmos, etc which can do multiple things way more efficiently. Many of these are OSS projects, so you wont get vendor lock-in.
I think the article is mainly attempting to provide you with a tool to calculate complexity. You can add additional columns to the calculator and make it your own for your needs. It's been used by some companies internally to compare complex systems or to migrate from an old system to a new system.
