Go has quietly become the language of data infrastructure: Kubernetes operators, ETL services, CLI tools, Prometheus exporters, the plumbing that moves data around a modern estate. So when a team wants one of those things to talk to IBM Netezza, they reach for nzgo, IBM’s open-source Go driver, wire it into Go’s standard database/sql, and expect it to just work.
It mostly doesn’t. We put the driver through the same engineering pass we recently gave the Python driver and the SQLAlchemy dialect, tested it live against both classic NPS 7.x racks and current NPS 11 systems, and found a stack of defects ranging from annoying to genuinely dangerous. We’ve fixed them all in an enhanced internal build.
The one that should worry you: SQL injection
The driver’s parameter handling – the ? placeholders every Go developer uses with db.Query – substituted values into SQL with no escaping whatsoever. A name as ordinary as O'Brien produced broken SQL. More seriously, any value containing a quote could break out of its string literal: a textbook SQL-injection vector, in the exact code path applications rely on to be safe. nil, booleans and timestamps weren’t handled at all; they errored out with “unknown type of parameter.”
Our build escapes parameters correctly (quotes doubled, verified against hostile inputs) and handles the full range of Go types. If you have any Go code passing user input to Netezza through this driver, this fix alone is the reason to switch.
Parameterised queries simply didn’t work on NPS 7
On classic NPS 7.x appliances – still a large part of the installed base – every parameterised query failed outright with a cryptic error about ANALYZE and prepared statements. The driver was asking the server to describe the query in a way NPS 7 refuses from a Go client. We detect the appliance generation once at connect and take the right path for each; parameterised queries now work everywhere.
Character corruption, quietly
Netezza stores CHAR and VARCHAR in LATIN9, and the driver was handing those bytes to Go as-is, so €, Š, ž and accented European text came back as garbage. (This is the same class of bug we found and fixed in the Python driver – the appliance behaves identically regardless of language.) Fixed: CHAR/VARCHAR now decode correctly, and we verified a full multilingual round-trip – Cyrillic, Arabic, Hebrew, Chinese, Japanese, Korean, Danish, emoji – comes back byte-exact through the ORM-style scan.
The one that bites you on Kubernetes
The driver looked up the OS user at connect time and dereferenced the result without checking for failure. In a container running under an arbitrary UID with no passwd entry – the normal case on OpenShift and scratch images – that lookup returns nothing and the driver panics on every single connection. For anyone deploying Go services in modern container platforms, the driver was a non-starter. Now guarded.
And the hard one we didn’t give up on: external tables on NPS 7
External tables are Netezza’s high-speed bulk load/unload mechanism, and they’re exactly what a Go ETL service wants. On NPS 7 they appeared completely broken through the driver – the appliance rejected the Go client’s request outright.
Our first pass concluded it couldn’t be fixed cleanly. We were wrong, and we went back and proved it properly against the appliance. The truth: NPS 7’s SQL parser doesn’t recognise the literal the Go driver sends to name itself, but the appliance is perfectly willing to serve the standard external-table data stream – which the driver already knows how to read – once you name the client with a literal it does recognise. The driver now detects the appliance generation and adapts automatically. Write your external-table statement the normal way and it works, unload and reload, on both NPS 7 and NPS 11, with international data intact. (The earlier “0 bytes” result that fooled us turned out to be an empty source table – NPS 7 doesn’t support the multi-row VALUES syntax our first test used to populate it. A good reminder that a failing test and a failing feature are not the same thing.)
nzgo or the ODBC driver?
The honest comparison. IBM ships an ODBC driver that works well, and there’s a place for it: if you already run the IBM ODBC stack, or need features beyond straight database/sql, use it. But it means installing and configuring native ODBC client libraries at the OS level on every machine and in every container image – a real burden for Go’s “single static binary” deployment model. The enhanced nzgo is pure Go: go get, one import, no OS-level driver, a binary you can drop into a scratch container. For the Kubernetes-operator, CLI-tool, microservice world where Go actually lives, that difference is the whole point.
A failing test and a failing feature are not the same thing. It’s worth the extra hour to tell them apart.
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 team tried nzgo against Netezza and hit the injection bug, the NPS 7 wall, or a container panic and moved on – it’s worth another look. The wall is gone. 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.
