Ask a .NET team to pull data from PostgreSQL and they add Npgsql to the project file and move on. Ask the same team to pull data from IBM Netezza and the afternoon disappears: install IBM’s ODBC client at the operating-system level, configure a DSN or wrestle a connection string, match the driver bitness to the process, then do it all again inside the Docker image. The application code was the easy part; the driver plumbing was the work.
We have now built the driver that removes all of that: a pure managed ADO.NET provider for Netezza. It speaks the appliance’s wire protocol directly over a TcpClient, in ordinary C#, with zero package dependencies. No ODBC. No native libraries. Nothing to install in the container.
The familiar API, doing the right things
The driver exposes the surface every .NET developer already knows: NetezzaConnection, NetezzaCommand, NetezzaDataReader, @name parameters. Dapper-style code reads exactly like it would against any other database.
Under that familiar surface, the details are handled the way Netezza actually requires. Parameters are bound injection-safely, with quotes doubled and backslashes deliberately left alone, because on Netezza a backslash inside a string is a literal character and “escaping” it would corrupt data. We test with hostile input: bind o'brien; DROP TABLE x-- as a parameter and it comes back out of the database as that exact inert string. Typed getters parse with the invariant culture, so a French or German host locale cannot quietly change your numbers.
Both appliance generations, one code path
Netezza estates span classic NPS 7.x racks and current NPS 11 systems, and the two differ on the wire: different protocol versions, different login hashing, different quirks. Like the rest of our driver programme, this provider uses a single connect-time code path that every generation accepts. The driver negotiates whichever authentication the appliance asks for and decodes both result formats the appliance uses, including the binary engine-tuple format that real table scans arrive in, across the full type system: every integer width, 38-digit numerics, dates, times, timestamps, intervals, booleans, and both character families, with the European encoding Netezza uses for CHAR and VARCHAR decoded correctly. Accented text, euro signs and Chinese come back byte-exact.
Every feature in this post was tested live against a real NPS 7.2 appliance and a real NPS 11.2 system before we called it done.
Bulk data and encrypted sessions included
External tables are Netezza’s high-speed bulk path, and they are the first thing a data service actually needs and the first thing most non-IBM drivers skip. This provider speaks the data channel in both directions: unload a query to a local file at wire speed, load a file into a table, and receive the appliance’s load diagnostics (.nzlog, .nzbad) when rows are rejected. We verified the full round trip, unload then reload, with international data intact, on both generations.
TLS costs one connection-string setting: SecurityLevel=3. The .NET SslStream does the encryption, and the driver accepts the self-signed certificates appliances actually present, including the weak-by-modern-standards ones on older NPS 7 racks that stricter stacks reject outright. The point of encrypting a session to an appliance you own is the encryption.
Honest edges
The provider is deliberately scoped to what it does well: connect, query, parameterised commands, readers, bulk external tables, TLS. Transactions ride the channel’s auto-commit behaviour (issue explicit BEGIN/COMMIT SQL if you need a block), there is no async surface yet, and unsupported ADO.NET corners throw a clear exception naming the method rather than returning a misleading default. NuGet publication is coming soon, so it will be one dotnet add package away.
The driver plumbing should never be the work. The application is the work.
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 C# service in your estate still reaches Netezza through an ODBC DSN somebody configured years ago and nobody dares touch, there is now a simpler way. 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.
