> Is there any good reason to use stored procedures in 2026?
more unhinged HN energy disconnected from reality
more unhinged HN energy disconnected from reality
Timeline
Post
Remote status
Context
3everyone who says "it's terrible to use these database features, this should all be application logic because... testing, and $reasons" seem to be from people who are NoSQL-brained and can't escape it
@feld maybe it depends on the features. When I was a DBA the programmers (ok, I also programmed too) avoided many database features. Stored procedures were harder to upgrade and were slower. There was a dream of being cross DB compatible too by sticking to the SQL standards as much as possible. We’d lived through many tech changes and wanted to minimize work if it’d be needed again.
@drewdaniels stored procedures were slower? Weird, doing that work in the database should be *faster* than doing it in the application layer.
Replies
2@feld the problem is that queries in the sproc either didn’t get optimized, or bypassed the cache I think. I think Percona used to have a blog post about it.
@drewdaniels Percona as in MySQL fork?