Announcing First Pure-Go CUBRID Driver: gocubrid

gocubrid is the first pure-Go CUBRID driver: a CUBRID Go driver that speaks the CAS broker wire protocol natively, with zero cgo and nothing beyond the Go standard library.

It registers as a standard database/sql driver, so adopting this CUBRID database driver takes a single import, and it is built for CUBRID migration work where static, portable binaries matter. gocubrid changes one thing fundamentally: no C toolchain, no CCI shared libraries, just go get and build.

go get github.com/hexacluster/gocubrid

Go 1.24+ | No CGO/C-libs | Zero dependencies | BSD-3-Clause

Why a new driver

Sometimes innovation comes from a requirement, and gocubrid is no exception. It started with a customer request: add CUBRID to DMAT, HexaCluster's migration assessment tool that analyzes how hard it is to migrate away from databases like Oracle, SQL Server, MySQL, and MariaDB. Supporting CUBRID meant talking to it from Go, and the only option was the cgo-based CUBRID/cubrid-go driver.

That driver fought us at every turn: performance bottlenecks, unreliable result-metadata extraction, and a build pipeline that had to drag the CUBRID client libraries through every CI/CD stage. The native dependencies made DMAT painful to build and run across operating systems, and getting a cgo CUBRID app working on macOS and Windows was a nightmare. Worst of all, DMAT is meant to run in air-gapped environments, yet the driver still demanded libcascci.so on the machine. To get out from under all of that, we wrote a pure-Go CUBRID driver.

The problem is structural: cubrid-go wraps the CCI C client library through cgo, and that single fact ripples through your whole pipeline: a C toolchain to build, the CUBRID client shared libraries (libcascci.so and friends) on every host, and a binary you cannot cross-compile. A pure-Go CUBRID driver pays off at each of those steps.

• Simpler CI/CD. Delete the "install CUBRID client libraries" step from your Dockerfiles and build agents. go build is the entire toolchain, so your pipeline has one fewer system dependency to pin, cache, and break on.
• Smaller, safer images. Pure Go builds into scratch or distroless. No client libraries ride along, so images are smaller, pull faster, and carry a smaller attack surface to audit and patch.
• Cross-compile from anywhere. Build linux/amd64 from an Apple-silicon laptop, or target arm64, by setting GOOS and GOARCH. No C cross-toolchain, no per-arch build host.
• Faster onboarding. A new engineer clones the repo, runs go get, and builds. No system packages, no LD_LIBRARY_PATH, no client-library version drift between someone's laptop and production.
• Timeouts that free resources. Every network call honors context.Context. When a request is cancelled or times out, the driver unwinds and releases the goroutine instead of blocking inside a C call you cannot interrupt.

Migrating from cubrid-go

Both drivers register the same database/sql name, "cubrid", so migrating is two edits: the blank import and the DSN.

Before, with CUBRID/cubrid-go:

import (
    "database/sql"

    _ "github.com/CUBRID/cubrid-go"
)

db, err := sql.Open("cubrid", "cci:CUBRID:host:33000:demodb:user:password:")

After, with gocubrid:

import (
    "database/sql"

    _ "github.com/hexacluster/gocubrid"
)

db, err := sql.Open("cubrid", "cubrid://user:password@host:33000/demodb")

Your queries, Rows, Result, and connection pooling are unchanged. Server and broker errors now surface as a typed *cubrid.Error you can match with errors.As.

The build changes the most. cgo disappears, and so does everything it dragged into your image:

Before:

# the CUBRID client libraries are needed to compile AND at runtime
ENV CGO_CFLAGS="-I$CUBRID/include"
ENV CGO_LDFLAGS="-L$CUBRID/lib -lcascci -lnsl -lpthread -lrt"
RUN go build -o /app .
# the runtime image must still ship libcascci.so and friends

After:

RUN CGO_ENABLED=0 go build -o /app .
# final stage can be FROM scratch: COPY --from=build /app /app

Before you migrate, skim the README's features and limitations.

---

---

When database/sql is not enough

Underneath the adapter sits the native cubrid package: one *cubrid.Conn is one socket (not goroutine-safe by contract, since pooling is the adapter's job), and it exposes the full broker protocol. The wire behavior was implemented against the BSD-licensed CUBRID JDBC driver as a protocol reference.

• Schema introspection - typed catalog helpers for tables, columns, primary keys, imported and exported keys, and indexes. Exactly what migration and tooling code reaches for.
• LOB streaming - BLOB and CLOB locators with chunked reads and appends, transaction-scoped, never buffering the whole value.
• Single round-trip batches - many statements in one round trip; per-row errors stay isolated and the server keeps going past a failed row.
• Savepoints and isolation - named savepoints, read-committed / repeatable-read / serializable isolation, and a configurable lock timeout.
• Stored procedures - CALL with scalar OUT and INOUT parameters you register and read back.
• Collections and exact decimals - SET, MULTISET, and SEQUENCE map to []any; NUMERIC scans exactly, with no float rounding.
• HA failover and TLS - standby brokers tried in order after the primary, and an optional TLS upgrade for the broker connection.

cfg, _ := cubrid.ParseDSN(dsn)
conn, _ := cubrid.Connect(ctx, cfg)
idxs, _ := conn.Indexes(ctx, "athlete") // typed schema introspection

Runnable, compile-checked examples live in the repository.

How it compares

	gocubrid	CUBRID/cubrid-go
Implementation	pure Go, native CAS wire protocol	cgo wrapper over the CCI C library
Build-time C toolchain	not needed	required (cgo + CCI headers)
Runtime shared library	none	libcascci.so on every host
CGO_ENABLED=0 static binaries	yes	no
Cross-compilation	any GOOS/GOARCH	tied to the host C toolchain
Dependencies	standard library only	CUBRID CCI client libraries
Schema introspection	typed helpers	raw catalog SQL only
LOB / BLOB / CLOB	chunked streaming locators	materialized as a string
Batch execution	one round trip per batch	per-statement round trips
Stored procedure OUT params	yes	not exposed

cubrid-go can still reach HA failover and TLS through the CCI connection string, and isolation or savepoints through raw SQL; the difference is whether the CUBRID Go driver gives you a typed API for it. The cubrid-go column reflects its public documentation (last released December 2022).

Proven where it counts

gocubrid advertises broker protocol V12 and gates features at runtime on what the broker negotiates, so there are no per-version code forks. The integration suite runs live against five releases: CUBRID 9.3.9, 10.1.8, 10.2.18, 11.0.16, and 11.4.5 (the primary target, where SSL and Java stored procedures are also verified).

The wire protocol code is tested at every level, from fully controlled unit tests to adversarial stress: codec tests against byte-exact fake brokers, golden wire frames captured from every live version and replayed offline, a race-enabled pool storm with a 100k-row streaming fetch and broker-restart recovery, and native fuzzing of every parser seeded from those golden frames.

gocubrid is open source under BSD-3-Clause. It is built and maintained by HexaCluster, where it backs our database migration services and broader commercial-to-open-source database migration work. Issues and contributions are welcome.

Get started

go get github.com/hexacluster/gocubrid

• Source and issues: https://github.com/hexacluster/gocubrid
• API docs: https://pkg.go.dev/github.com/hexacluster/gocubrid
• README: https://github.com/hexacluster/gocubrid/blob/dev/README.md

---

If you need expert support migrating legacy or complex Oracle, SQL Server, MySQL, MariaDB, DB2, Sybase ASE, or Cassandra databases to PostgreSQL or distributed databases, we’re here to help.

HexaCluster provides end-to-end migration and modernization services, including application migration and modernization, database migration, and PostgreSQL consulting such as performance tuning, health audits, managed DBA services, and 24/7/365 support.

To start a conversation or explore how we can support your migration journey, please contact us at connect@hexacluster.ai

Subscribe to our Newsletters and Stay tuned for more interesting topics.