// the find
afair/postgresql_cursor
ActiveRecord PostgreSQL Adapter extension for using a cursor to return a large result set
A small ActiveRecord extension that wraps PostgreSQL's native cursor support so you can iterate over huge result sets without loading everything into memory. Useful for background jobs, data migrations, or batch processing scripts where find_each's constraints (numeric PK order, re-querying per batch) are a real problem.
Addresses specific, documented gaps in find_each/find_in_batches: you keep your own ORDER BY, the query runs once instead of per-chunk, and PKs don't need to be numeric. The FOR UPDATE + block_size option gives you row-level locking for safe concurrent batch updates, which is the kind of thing people usually hand-roll badly. Returning raw hashes via each_row instead of instantiating models is a legitimate 4x speedup for read-heavy jobs, and the Enumerable/lazy integration means it composes with map/reduce instead of forcing you into a callback-only API.
Hard PostgreSQL lock-in with no abstraction layer, so it's a non-starter the moment you're on MySQL or multi-database. Eager loading is explicitly broken — the README admits ActiveRecord's association loading doesn't join when this gem hooks to_sql, so you'll get N+1s if you're not careful. WITH HOLD cursors held open across commits is a footgun for connection pool exhaustion that gets one line of documentation and no guidance on timeouts or pool sizing. Test coverage looks thin — a single test file and no CI config visible beyond an old .travis.yml, for a library whose whole value proposition is correctness under large datasets.