← Back to blog
Xinchuang 4 min read 炬鲸团队

Connecting an Observability Platform to Domestic Databases: OceanBase, DM, and GaussDB

Sovereign-computing projects require domestic databases. This article covers connection config, dialect differences and common pitfalls when connecting an observability platform to OceanBase (MySQL mode), DM and GaussDB, with example connection strings and migration advice.

Domestic databases are unavoidable in sovereign-computing projects

In sovereign-computing projects, domestic databases are usually a hard item on the acceptance checklist, and that requirement extends to supporting systems, not just the core business. The observability platform's own metadata and configuration store — users, alert rules, query permissions — must also land on a domestic database. Observe supports the MySQL wire protocol, which makes it compatible with a large family of domestic databases out of the box. But "MySQL-compatible" does not mean "zero changes": a few details are worth handling up front, or you will pay for them after go-live. This article records what we learned connecting the platform to OceanBase, DM and GaussDB.

OceanBase: nearly seamless in MySQL mode

OceanBase's MySQL-compatible mode is the smoothest option we have seen. You only need to swap the host and port in the connection string to point at OceanBase's OBProxy:

mysql -h obproxy.example.com -P 2883 -u observe -p

No application code changes are required. Two things to watch. First, align OceanBase's sql_mode with the MySQL 5.7 defaults; leaving ONLY_FULL_GROUP_BY enabled is the most common cause of mysterious query errors during initialization. Second, create the tenant in advance and specify it during platform initialization — never run business tables in the sys tenant, which is reserved for OceanBase's own management and will cause permission errors down the line.

DM (Dameng): compatible, but mind the dialect

Dameng offers a MySQL-compatible mode, yet some SQL dialect differences remain. In practice we have hit three recurring problems:

  • Pagination: prefer DM's compatibility mode so LIMIT behaves as expected; otherwise you must fall back to TOP or ROW_NUMBER(), which breaks most ORMs.
  • Charset: always specify UTF-8 (spelled UTF8 in DM). Skip this and Chinese alert content turns into unreadable mojibake in dashboards.
  • Driver: use DM's official JDBC driver, with a connection string like jdbc:dm://host:5236?schema=OBSERVE.

Create a dedicated schema for the platform in DM rather than sharing one with other business systems, so upgrades and backups stay independent. If you already run DM instances, ask the DBA for the exact charset and dialect settings before you start, rather than discovering them through a failed initialization.

GaussDB: distinguish centralized from distributed

GaussDB comes in two forms: a centralized (single-node) deployment and a distributed deployment within the openGauss/MogDB ecosystem. When connecting the platform, prefer the centralized deployment, whose behavior is close to traditional MySQL/PostgreSQL. The distributed version incurs performance overhead on cross-node joins, so keep the metadata tables on a single shard and avoid cross-shard foreign keys.

Example connection string (openGauss driver):

jdbc:opengauss://host:5432/observe?currentSchema=observe

Migration and acceptance advice

When migrating the observability platform's metadata store to a domestic database, follow this rhythm: run on a test instance for two weeks, verify that alert rules and permission data match the old store exactly, cut over to the new primary, then keep the old database for one more week as a rollback path. During acceptance, check three things specifically: Chinese content renders without mojibake, alert rules and historical data are intact, and query performance does not regress.

Keep this checklist handy before you start: confirm the target database's compatibility mode and version up front; align charset (UTF8) and sql_mode before initialization; use the vendor's official JDBC driver, not a generic one; keep the platform's schema or tenant separate from business data; and test for two weeks before cutting over while keeping a one-week rollback window. Domestic database adoption is not just swapping a connection string — confirming charset, dialect and driver ahead of time saves a great deal of rework after go-live, and it is what separates a smooth rollout from a long one.

In short: pick the database your compliance review actually requires, confirm charset and dialect before the first initialization run, and keep a rollback window open — the rest is mechanical.