Every long-lived Netezza estate has them: the Perl scripts. The nightly extract someone wrote in 2011, the reconciliation job that finance quietly depends on, the housekeeping cron that nobody wants to touch. Perl was the glue language of the data-warehouse generation that Netezza belongs to, and in these estates it still is.
What those scripts never had was a decent driver. The choices were shelling out to nzsql and parsing its output, or DBD::ODBC over IBM’s client stack, with the install-and-configure ritual repeated on every host that runs a script. Both work, in the way that things you would rather not look at work.
So we built the missing piece: a pure-Perl driver for Netezza. Netezza::Client implements the appliance’s wire protocol directly over a socket, using nothing but core Perl modules, and DBD::Netezza wraps it in the DBI interface every Perl programmer already knows. No ODBC, no XS, no compiler, no CPAN build chain. Copy two .pm files onto a host and the script connects.
DBI, exactly as you expect
Existing DBI code works unchanged: DBI->connect('dbi:Netezza:host=...;database=...'), prepare, execute with ? placeholders, fetchrow_array, selectall_arrayref, do returning real affected-row counts. Placeholders are bound injection-safely, quotes doubled and backslashes deliberately left alone, because on Netezza a backslash inside a string is a literal character. We test with hostile input; o'brien; DROP TABLE x-- comes back out of the appliance as exactly that inert string.
The driver is honest at its edges too. The channel it speaks is auto-commit, so rather than pretend, AutoCommit => 0 is refused with a clear message and explicit BEGIN/COMMIT SQL still works.
Both appliance generations, one code path
The scripts we are describing tend to run against the oldest hardware in the estate, so the driver treats classic NPS 7.x racks and current NPS 11 systems as equal citizens. It negotiates a connect-time code path both generations accept, follows whichever login hashing the appliance asks for, and decodes both result formats the appliance uses, including the binary engine-tuple format real table scans arrive in. The full type system comes through correctly: every integer width, 38-digit numerics, dates, times, timestamps, intervals, and both character families, with the European encoding Netezza uses for CHAR and VARCHAR decoded properly. Accented text, euro signs and Chinese survive the round trip byte-exact.
Every feature here was tested live against a real NPS 7.2 appliance and a real NPS 11.2 system before we called it done.
Bulk paths and encrypted sessions
External tables, the appliance’s high-speed load and unload mechanism, work in both directions from a Perl script: unload a query to a local file at wire speed, load a file into a table, and receive the appliance’s .nzlog and .nzbad diagnostics when rows are rejected. For the extract-and-ship jobs these scripts mostly are, that is the feature that matters.
TLS is one option: security_level => 3 and the session is encrypted via IO::Socket::SSL, including against older NPS 7 racks whose self-signed certificates modern OpenSSL defaults reject; the driver handles that case deliberately.
Honest edges
The DBI layer covers what estate scripts actually use: statements, parameters, fetches, counts, ping. There is no server-side cursor streaming (results are fully fetched, which is how these scripts consume them anyway), and CPAN publication is coming soon, so a single cpanm will eventually be the whole install.
The scripts nobody wants to touch are exactly the ones that deserve the most boring, dependable driver underneath them.
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 your estate still runs its nightly Perl through nzsql pipes or a fossilised ODBC setup, this is the low-risk replacement: same DBI code, one less layer to break. 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.
