Real-world differences when running OBSERVE on DM8, KingbaseES, and OceanBase: case sensitivity, SQL dialect, connection pooling and drivers, pagination syntax, plus benchmark results and selection advice.
Moving an observability platform's metadata, alert rules, and search indexes onto a domestic database is not "swap the connection string." DM, KingbaseES, and OceanBase each have their own dialect and default behavior; the more generic your SQL, the fewer traps you hit. This section covers the real differences we encountered running OBSERVE on all three, split into "avoidable up front" and "must adapt on site."
This is the most common trap, and nearly everyone steps in it. DM8 is case-sensitive by default: unquoted table and column names get normalized to uppercase at creation, so select user_id from t_user can fail because the column is actually stored as USER_ID. KingbaseES defaults to an Oracle-compatible mode with similar behavior. OceanBase in MySQL-compatible mode is case-insensitive, behaving closer to MySQL.
Concretely: on DM, CREATE TABLE t_user(user_id INT) stores the column as USER_ID, so SELECT user_id FROM t_user throws an "invalid column name" error. Either uppercase everything at create time, or quote identifiers and stay consistent.
The adaptation: quote identifiers or uppercase them consistently in schema scripts, and don't expect "both ways work." OBSERVE ships per-dialect init scripts — run the matching one rather than hand-editing.
The dialect differences cluster in a few spots:
LIMIT ? OFFSET ? or ROWNUM; OceanBase's MySQL mode uses LIMIT ?, ?. Paginating large log result sets is a hot path, and getting it wrong breaks page turns immediately. For log search, DM paginates with ... ORDER BY ts DESC LIMIT 100 OFFSET 200, while OceanBase's MySQL mode uses LIMIT 200, 100;CONCAT, SUBSTR, IFNULL/NVL differ by name — DM and KingbaseES lean Oracle (NVL), OceanBase MySQL mode leans MySQL (IFNULL);TIMESTAMP precision and NOW()/SYSDATE semantics differ, so log timestamp fields need a unified mapping.Our approach is to confine dialect differences to an ORM dialect adapter; the business layer writes standard SQL and the adapter translates to each database's dialect. Switching databases then means changing one place instead of scattering edits across the project.
Driver versions are hard requirements: DM needs its official JDBC driver, KingbaseES its own driver, and OceanBase speaks the MySQL protocol (a MySQL driver works if you disable certain MySQL-specific options). Pool parameters need tuning too: domestic databases have higher per-connection costs under concurrency, so raise the minimum pool size and relax idle-reclaim timers to avoid connection churn slowing searches during peak. Also pin timezone and charset in the connection string (serverTimezone, useUnicode=true&characterEncoding=utf8) rather than relying on defaults, which differ across the three databases. Test the pool under a realistic concurrent load before cutover — connection handshakes are where subtle driver differences surface.
Init scripts should cover five steps — create database, tables, indexes, partitions, and seed data — and must be idempotent (safe to re-run). Xinchuang environments are often air-gapped with scripts run by hand, so write them as explicitly as possible and avoid interactive prompts.
On identical hardware (8C32G, SSD) we ran simple write/read benchmarks on the three databases. Treat these as rough guidance, not gospel — benchmark against your own load:
Selection advice: single datacenter with moderate data volume — pick DM or KingbaseES for simplicity; multiple datacenters, large volume, horizontal scaling — pick OceanBase. Don't reach for the most complex option just because "localization" is in the brief; start from data volume and ops capability.
Switching databases isn't done when the connection string is. Use this checklist: run the init scripts three times idempotently with no errors; run core queries (log pagination, metric aggregation, alert-rule reads) on the target database and record P95 latency; confirm case sensitivity, timezone, and UTF-8 charset one by one; run a backup/restore drill once. Finish the checklist, and only then is the domestic-database adaptation actually done. If anything fails, an air-gapped environment makes iterating slower, so budget extra time for the first database you bring up.