How does this handle prepared statement caching compared to writing sqlx queries directly? Been burned before by N+1 prepared statement creation in high-throughput services. Also curious if there's a migration story since sqlc plugins are relatively new, did you hit any gotchas moving existing sqlx codebases over?
This plugin uses sqlx underneath which handles prepared statement caching. Regarding migration, we just used a coding agent to migrate our database infrastructure to it. It takes <20 minutes and remember this really only helps with static queries. We do support sqlc's dynamic queries though.
Tip: you can use case statements and etc. to create static queries even when you have conditionals.
How does this handle prepared statement caching compared to writing sqlx queries directly? Been burned before by N+1 prepared statement creation in high-throughput services. Also curious if there's a migration story since sqlc plugins are relatively new, did you hit any gotchas moving existing sqlx codebases over?
This plugin uses sqlx underneath which handles prepared statement caching. Regarding migration, we just used a coding agent to migrate our database infrastructure to it. It takes <20 minutes and remember this really only helps with static queries. We do support sqlc's dynamic queries though.
Tip: you can use case statements and etc. to create static queries even when you have conditionals.
Also, read https://news.ycombinator.com/newsguidelines.html#generated