The most difficult part is managing the delivered / processed state and ordered delivery. Consistent ordering of receipt into a distributed buffer is a great challenge. Most stacks do that pretty well. But deciding when a message has been processed and when you can safely decide not to deliver it again it is especially challenging in a distributed environment.
That is sort of danced around a bit in this article where the author is talking about dropped messages, etc. It is tempting to say "use a stream server" but ultimately stream servers make head-of-line accounting the consumer's responsibility. That's usually solved with some kind of (not distributed) lock.
Kafka is great for streaming use cases, but the big advantage of Postgres-backed queues is that they can integrate with durable workflows, providing durability guarantees for larger programs. For example, a workflow can enqueue many tasks, then wait for them to complete, with fault-tolerance guarantees both for the individual tasks and the larger workflow.
I guess if you use different topics(queues) in Kafka you can do all this by the help of a processor like Storm, Spark etc, routing messages to different topics hence a workflow.
Huh? Kafka messages are durable just like Postgres commits are durable. That’s why it’s used for things like Debezium that need a durable queue of CDC messages like those from the Postgres WAL.
There’s nothing inherently different about the durability of Postgres that makes it better than Kafka for implementing durable workflows. There are many reasons it’s a better choice for building a system like DBOS to implement durable workflows – ranging from ergonomics to ecosystem compatibility. But in theory you could build the same solution on Kafka, and if the company were co-founded by the Kafka creators rather than Michael Stonebraker, maybe they would have chosen that.
I suspect there's a lot of nuance you can't really capture in a study like this.
How you use AI will depend on the model, the tools (claude-code vs cursor vs w/e), your familiarity and process (planning phases, vibe coding, etc.), and the team size (solo dev versus large team), your seniority and attention to detail, and hard to measure effects like an increased willingness to tackle harder problems you may have procrastinated on otherwise.
I suspect we're heading to a plateau. I think there's a ton of polish that can be done with existing models to improve the coding experience and interface. I think that we're being massively subsidized by investors racing to own this market, but by the time they can't afford to subsidize it anymore, it'll be such a commodity that the prices won't go up and might even go down regardless of their individual losses.
As someone who knows they are benefitting from AI (study shmuddy), I'm perfectly fine with things slowing down since it's already quite good and stands to be much better with a focus on polish and incremental improvements. I wouldn't invest in these AI companies though!
> As someone who knows they are benefitting from AI (study shmuddy)
XD
Look, I get it, I still use it, but you have to admit, people also think that various bogus home remedy totally helps them get over a cold faster. There's absolutely a possibility it in no way makes us faster.
Now, you did say "benefit", that's more broad, and you implied things like polish, I've seen others mention it just makes the work easier, that could be a win in itself (for the workers). Maybe it's about accessibility. Etc.
I do think though, right now, we're all in the "home remedy" territory, until we actually measure these things.
I consider myself to be something of a cynic. That’s not to say I couldn’t be bamboozled in some circumstances.. . but I think it unlikely is this case, because I am simply OK with AI being a complete failure if indeed it is. I don’t have an irrational need for this to work. If anything I was very skeptical to start with and was pleasantly surprised to find it useful.
I’m not pushing Amway, I don’t own any crypto, and I’m bearish on the S&P right now due the market cap concentration at the top. And yet I swear that claude code is working for me quite well.
> Now, you did say "benefit", that's more broad, and you implied things like polish, I've seen others mention it just makes the work easier, that could be a win in itself (for the workers). Maybe it's about accessibility. Etc.
Yes exactly, and this is the (ambiguous) metric that I actually care about. I suspect this study will go down in history as useless and flawed, not to be overly harsh :)
I sort of wonder if AI pushes people to stay "in the weeds". I've noticed that the speed of my software development hinges a lot on decisions that require me to take a step back (e.g. Am I using the right tool? Is this feature necessary? etc)
Pytype was cool before Python type annotations became widespread. It seems to me like the industry is naturally moving toward native type annotations and linters and away from static analyzers like Pytype and mypy.
Well yes but with native annotations the linter you’re already using can do a lot of the type checking work so for many teams it’s not worth it to add Pytype or mypy
A counter example would be Weaveworks(folks behind Flux/FluxCD and many other widely used oss tools). I'm sure the ex employees would've preferred to get acquihired vs closing up for good. I highly doubt Styra was pulling in enough money to fund their business, and the days of zirp are long gone, so I doubt they would've been able to raise another round to keep the lights on for another few years.
ControlPlane was able to hire (not acqui-) a few of the FluxCD maintainers and other WeaveWorks staff to continue supporting the project — we did what we could, agree this is better for Styra folk than the uncertainty of closing up shop.
The shop (Styra) did get closed. A few of the most senior maintainers were hired by Apple. Many - including anyone not directly involved in engineering of the OSS product - are now looking for jobs.
They already had made a strong statement by choosing BSD when GPL was at their disposal. That is a much stronger statement than some blog post that reflects a momentary snapshot of their plans.
It is just that people don't hear what they don't want to hear. Every BSD or MIT is a loud and clear statement to deny the guarantee that derivative works will remain free and open.
Because Redis said they would never do something and then changed their mind (which makes the whole concept of saying you will never do something useless), while Amazon never said they wouldn’t use open source software for free (which is their right).
AWS, GCP, surely are invested: they paid for ValKey, they forked to avoid doing revenue sharing with Redis in any way :D IMHO it's a matter of what the community does, and it, in turn, this depends on how well we are able to develop Redis.
It's not just licensing and hyper-scalers, it's also a matter of development quality and direction. For instance, now in Redis you can find substantial more stuff not available in ValKey, including hash items expires, Vector Sets that are very useful for a number of things, the probabilistic data structures just introduced with Redis 8, and so forth.
If Redis is superior then sticking with Valkey would just be throwing good money after bad. Hopefully those companies are competent enough to understand the concept of sunk costs.
Maybe Valkey has served its purpose in pressuring Redis into playing ball.
Just answering "why would". Whether or not Redis is better then Valkey or if it would be worth it to switch back is not something I know.
AWS and GCP offer valkey-based versions of products that are typically based on Redis, but those versions are currently, generally, preview-grade, and statistically zero customers are using them. They still offer the original, Redis-based versions of those products, which, statistically, 100% of their customers are using.
Do you have data to back up your claims? I see a lot of customer claims for Valkey here, https://aws.amazon.com/elasticache/customers/. Neither of the AWS or GCP offerings are in preview.
valkey was introduced as an opt-in alternative to Redis as an implementation choice for specific products offered by the the major cloud providers approximately 9 months ago. Generally valkey is shown as a preview or beta or whatever option. Nobody has performed any kind of automatic or default transition from Redis to valkey for existing customers.
My claim that statistically zero (cloud provider) customers are using valkey should, I sincerely hope, be self-evident.
>My claim that statistically zero (cloud provider) customers are using valkey should, I sincerely hope, be self-evident.
I have no idea what the actual stats are. But no, I don't find your "statistically 0%" to be self-evident, especially in light of the other comments and links in this thread, and what I've heard elsewhere.
I was hoping, since you presented it so confidently, that you had something more than "trust me". In another comment you say you have evidence of marketshare, maybe you could post that?
I recently moved on to a new company, but my prior company had a pretty large scale Elasticache Redis deployment in production (over 50 large clusters in us-east-1), and were in the middle of a complete migration to Valkey due cost savings, improved performance, and reduction in memory usage.
We've already completed migrating several large production clusters and I can confidently say that the migration had been pretty smooth and seamless.
Valkey is certainly production ready (at least on AWS it is). The team is looking forward to expedite and complete the migration
Our company made the switch over to Valkey, and we've invested hundreds of engineering hours into it already. I don't see us switching back at this point especially when it's clear Redis could easily pull the bait-and-switch again.
While it's likely an easy process to drop in valkey, creating the new instances, migrating apps to those new instances, and making sure there's not some hidden regression (even though it's "drop in") all takes time.
At a minimum, 1 or 2 hours per app optimistically.
My company has hundreds of apps (hurray microservices). That's where "hundreds of hours" seems pretty reasonable to me.
We don't have a lot of redis use in the company, but if we did it'd have taken a bit of time to switch over.
Edit: Dead before I could respond but I figured it was worthwhile to respond.
> It's literally just redis with a different name, what is there to test?
I've seen this happen quite a bit in opensource where a "x just named y" also happens to include tiny changes that actually conflict with the way we use it. For example, maybe some api doesn't guarantee order but our app (in a silly manor) relied on the order anyways. A bug on us, for sure, but not something that would surface until an update of redis or this switch over.
It can also be the case that we were relying on an older version of redis, the switchover to valkey necessitates that we now bring in the new changes to redis that we may not have tested.
These things certainly are unlikely (which is why 1 or 2 hours as an estimate, it'd take more if these are more common problems). Yet, they do and have happened to me with other dependency updates.
At a minimum, simply making sure someone didn't fat finger the new valkey addresses or mess up the terraform for the deployment will take time to test and verify.
There's definitely pros and cons to this approach.
The pro being that every service is an island that can be independently updated and managed when needs be. Scaling is also somewhat nicer as you only need to scale the services under heavy load rather than larger services.
It also makes for better separation of systems. The foo system gets a foo database and when both are under load we only have to discuss increasing hardware for the foo system/database and not the everything database.
The cons are that it's more complex and consistency is nearly impossible (though we are mostly consistent). It also means that if we need a system wide replacement of a service like redis, you have to visit our 100+ services to see who depends on it. That rarely comes up as most companies don't do what redis did.
Indeed. Microservice zealot 'architects' love to ignore the work that has to into each microservice and the overhead of collaboration between services. They'll spend a couple of years pretending to work on that problem in any meaningful way, then move on to a different company to cause similar chaos
that’s a loaded statement without understanding the company.
Sometimes large companies acquire smaller companies and keep the lights on in the old system for a while. They may not even use a similar tech stack!
Sometimes they want to cleanly incorporate the acquired systems into the existing architecture but that might take years of development time.
Sometimes having a distributed system can be beneficial. Pros / cons.
and sometimes it’s just a big company with many people working in parallel, where it’s hard to deploy everything as a single web app in a single pipeline.
My understanding is that Valkey was forked directly from redis. So assuming you migrate at the forks point-in-time, then it literally is the same code.
Yes, but not the same infrastructure and configuration and documentation. Any reasonable operation will also do validation and assurance. That adds up if you have a sizable operation. "Hundreds of hours" is also not some enormous scale for operations that, say, have lots of employees, lots of data, and lots of instances.
The part you are thinking of is not the time consuming part.
At the very least you have to validate everything that touches redis, which means finding everything that touches redis. Internal tools and docs need to be updated.
And who knows if someone adopted post-fork features?
If this is a production system that supports the core business, hundreds of hours seems pretty reasonable. For a small operation that can afford to YOLO it, sure, it should be pretty easy.
The negative effect is that you have to bring the lawyers back in, and they tend to take an extremely conservative position on what might be litigated as offering “Redis-as-a-service”.
Many legal departments cannot afford nuance when a newsworthy license change occurs. The kneejerk reaction is to switch away to mitigate any business risk.
Why did you not pay Redis for a licence instead? I'm genuinely curious. Did you feel uncomfortable being tied to a license fee that might increase in the future, or was it just too expensive?
how does it take hundreds of hours to swap out a back end when you're using a trivial protocol like redis?
did you switch out the client or something? maybe the problem is not using pluggable adapters? is your business logic coupled to the particular database client API? oof.
I know the cluster clients are different (been there, done that) but hundreds of hours, seriously? or was that just hyperbole?
I think you might underestimate how little time hundreds of hours is. It's very, very easy to reach your first hundred hours in a task, e.g. taking a 40 hour week, 3 engineers = 120 hours.
If valkey is working, why spend that time reverting to redis, when you could be spending it on things that are actually going to provide value?
Hundreds could be 200 which, at 10 hours a day 5 days a week, is like a week and a half for a team of 3. It seems quite possible if you had to do testing/benchmarking, config changes, deploy the system, watch metrics, etc.
My company is relatively small. With probably 6 separate redis instances deployed in various places (k8s, bare metal, staging and prod environments) and dozens of (micro)services using them it's probably at least 40 hours (one person-week) to migrate everything at this point. Also there are things like documentation, legacy apps that keep working but nobody wants to spend time updating them, naming problems everywhere (renaming "redis" everywhere with zero downtime would be a huge pain), outdated documentation, possibly updates in CI, CD, and e2e tests, and probably more problems that ight become apparent in scale.
And we're honestly not large. For a mid size company, hundreds hours sound reasonable. For a big company the amount of work must be truly staggering.
By switch I mean that all new projects use Valkey instead of Redis, and we've invested hundreds of hours into those new projects. We've also tried stuff with the Valkey Glide client.
I'm having trouble in my head understanding how these workflows are actually executed in the open-source version. Are there workers somewhere? How do we provision those and scale those up and down?
You run it as a daemon. The example in the readme is a fastapi app, for example. You would scale them the same way as any other long running app -- either behind a load balancer like haproxy or nginx or some other app runner.
We were reluctant to add a chat interface at first tbh, but there were so many real-world cases where a single-pass interaction just wasn't enough. Debugging logs is another case.
