Ruby earns its living in the layer where data work meets people: Rails back-offices, reporting portals, Sidekiq jobs that shuttle data between systems overnight. When one of those needs a number out of IBM Netezza, the team hits an awkward truth: there has never been a real Ruby driver. The options were an ODBC gem compiled against IBM’s client libraries, or shelling out to nzsql and parsing text. Both put a native dependency between your app and the warehouse, and both are the kind of thing that breaks on the next base-image upgrade.
We took a different route and wrote the driver itself: pure Ruby, standard library only. It opens a socket to the appliance, speaks Netezza’s wire protocol directly, and needs precisely zero gems. Not “few dependencies” – none. require 'netezza', connect, query.
Small API, correct behaviour
The interface is what a Ruby developer would sketch on a whiteboard: connect, query returning columns and rows, query_params for ? placeholders, do for statements that return a row count. Values come back as strings decoded exactly as the appliance sent them, with nil for SQL NULL.
The correctness lives underneath. Parameters are bound injection-safely, with quotes doubled and backslashes deliberately untouched, because on Netezza a backslash inside a string is a literal character. Bind o'brien; DROP TABLE x-- and it comes back as that exact inert string. Real table scans arrive in the appliance engine’s own little-endian binary tuple format, and the driver decodes the whole type system from it: every integer width, 38-digit numerics (Ruby’s arbitrary-precision integers make that one almost unfairly easy), dates, times, timestamps, intervals, and both character families, including the European encoding Netezza uses for CHAR and VARCHAR on disk. Accents, euro signs and Chinese come back byte-exact.
Old racks and new, one code path
The driver uses one connect-time code path that classic NPS 7.x racks and current NPS 11 systems both accept: the appliance picks its login hashing, the driver follows, and everything downstream is identical. Every feature in this post ran live against a real NPS 7.2 appliance and a real NPS 11.2 system before we called it done.
That includes the two capabilities that usually get skipped. External tables, Netezza’s high-speed bulk load and unload, work in both directions from Ruby, log-file diagnostics included, which is exactly what an overnight data-shuttling job wants. And TLS is one keyword argument: security_level: 3 encrypts the session through Ruby’s own OpenSSL binding, including against older NPS 7 racks whose self-signed certificates modern OpenSSL defaults refuse.
Honest edges
This is a driver, not an ORM: there is no ActiveRecord adapter yet, results are fully fetched rather than streamed, and the channel is auto-commit (explicit BEGIN/COMMIT SQL works). A gem on RubyGems is coming soon. Until then it is a single plain Ruby file, which is its own kind of dependency management.
Zero gems is not a constraint we suffered. It is the deployment story.
Where you get it
We did not build this for ourselves. Our software is written in Python, so nothing in our stack uses it; it exists because the gap did, and because other teams kept falling into it. If a Rails app in your estate has been screen-scraping nzsql output because the ODBC gem was too fragile to keep alive, there is now a one-file replacement. Talk to us if you want it in your own estate.
Built from the published open source Netezza drivers (IBM/nzpy and IBM/nzalchemy under Apache-2.0, IBM/nzgo under MIT), verified live against both NPS 7.2 and NPS 11.2, and produced without decompiling, disassembling or inspecting any IBM proprietary binary.
Running Netezza? Let’s talk. Smart Associates has been engineering on IBM Netezza for two decades: disaster recovery, migrations, performance and the deep platform work in between. If any of the above sounds familiar, why not get in touch.
