"good performance" from an RDB compared to a special purpose KV store interface is a very fuzzy concept indeed

nothing is ever as fast as what is written specific for a task, unless it has a good compiler and the language is simple enough it doesn't take so much resources it destroys the benefit for JIT (you could make JIT compiled search functions out of sql with go from a reasonably indexed data source that probably would beat any SQL engine)

i find it sad that i have to explain these simple physical laws of computer language processing to people who think they understand how computers work and think that sql is *always* better

no, it's not, it's lazy better, it's not faster better

Reply to this note

Please Login to reply.

Discussion

And I don't think any educated engineer expects an RDB to perform better than a KV, that's the whole point, I don't have a key, I need to query the data within the rows. These basics are taught in 200 level data structures courses that every undergrad in a CS or CPE degree must understand.

In my testing of dotnet, the EF Core framework averaged faster response times at every query I passed to it compared to hand compiled SQL queries for my use cases. Optimized stored procedures were the only performance benefit when requesting rows with primary keys (which is basically never). After the queries are cached in efcore, the performance is as good or better 99% of the time for my use cases, which is also the general consensus around most ORMs. And beyond this caching is used, where cache optimized KV stores blow the doors of KV databases, so I get the best of both.