▲ 22 ▼ Building a Reliable PostgreSQL Queue: Concurrency, Crashes, Retries, and Scale (blog.master.dev) submitted 1 day ago by codeinabox@programming.dev to c/postgresql@programming.dev 3 comments fedilink hide all child comments
[–] anzo@programming.dev 1 point 1 day ago (1 child) Would this be a replacement for Valkey in small scale? permalink fedilink source hideshow 1 child comment replies: [–] francisco_1844@discuss.online 2 points 2 hours ago Short answer, maybe. Until you specify your needs or use case it is very difficult to say. In general, most if not all, benchmarks I have seen comparing Postgres to RAM key value stores has always had postgres coming significantly slower. If speed is the most important factor then likely no, you still need a key value store. Also, you wrote "small scale", but even that can be ambiguous. Is it small scale because it is small, but you still need fast lookups? or is it "small scale" because it is a small setup and speed is not an issue? It ultimately comes down to your needs and your appetite for having a second technology if you already have postgres. Sometimes, even if a second technology is better at something, the overhead of having the second technology may not be worth it. permalink fedilink source parent
[–] francisco_1844@discuss.online 2 points 2 hours ago Short answer, maybe. Until you specify your needs or use case it is very difficult to say. In general, most if not all, benchmarks I have seen comparing Postgres to RAM key value stores has always had postgres coming significantly slower. If speed is the most important factor then likely no, you still need a key value store. Also, you wrote "small scale", but even that can be ambiguous. Is it small scale because it is small, but you still need fast lookups? or is it "small scale" because it is a small setup and speed is not an issue? It ultimately comes down to your needs and your appetite for having a second technology if you already have postgres. Sometimes, even if a second technology is better at something, the overhead of having the second technology may not be worth it. permalink fedilink source parent