Deploying on LoongArch + Kylin V10 + openGauss

LoongArch is neither ARM nor x86

We've written about Kunpeng + Kylin + Dameng and Phytium + UOS + Kingbase before; this is the third combination: a Loongson 3A5000 processor, Kylin V10, and openGauss. What makes Loongson different is the instruction set — LoongArch is Loongson's own architecture, neither x86 nor ARM. That creates a practical problem: most "domestic" binaries ship only x86 and aarch64 builds, and the LoongArch build is either missing or lags behind. When you choose a CPU architecture for a xinchuang project, you're deciding the availability of every piece of software downstream — decide this at project start, not after procurement.

Environment and preparation

• CPU: Loongson 3A5000 (LoongArch, 4C/8T) or 3C5000 (server class)
• OS: Kylin Server V10 (loongarch64)
• Database: openGauss 5.0 (standalone)
• Deployment: bare metal + systemd

Confirm three things up front: the OS is loongarch64, not mips64el (Loongson's older architecture — easy to mix up); openGauss has an official LoongArch release; and OBSERVE ships a loongarch64 offline bundle. Run uname -m before installing to confirm you're on loongarch64.

Deployment steps

tar -xzf jjhub-observe-2.6-loongarch64.tar.gz
cd jjhub-observe-2.6-loongarch64
./install.sh --db opengauss --db-host 10.0.0.31 --db-port 5432

openGauss listens on 5432 by default (PostgreSQL protocol). The installer creates the database and users automatically; use a dedicated business account rather than the omm superuser for business connections. openGauss enables resource pools and connection limits by default, so the business account needs explicit grants or the connection count will be pinned at the default.

openGauss adaptation notes

openGauss is a fork of the PostgreSQL 9.2 branch with most PG syntax compatible, but there are differences:

• Some extensions outside pg_catalog aren't supported, so the metadata layer has to avoid them.
• Paging uses LIMIT ... OFFSET like PG, but openGauss performs poorly on large OFFSET values — deep paging should use cursors or keyset pagination.
• Set UTF8 explicitly at database creation; openGauss's default locale may not be UTF8, which garbles Chinese log fields.

A word on compatibility mode

Unlike Dameng, which defaults to an Oracle-style dialect, openGauss is PostgreSQL-native, so code written for PostgreSQL mostly ports over with little friction. The catch is the version gap: openGauss tracks the PG 9.x lineage, so any syntax or feature introduced after PG 10 — newer JSON operators, some window-function behavior — needs to be checked, not assumed. Run a SQL compatibility audit against your metadata layer's queries before you commit to the platform.

Parameter tuning

In postgresql.conf:

shared_buffers = 4GB
max_connections = 300
synchronous_commit = off

openGauss flushes WAL synchronously by default, which is expensive under heavy write load. synchronous_commit = off cuts write latency substantially at the cost of losing the last transaction in an extreme failure. That's fine for log ingestion ("losing a few lines is tolerable") but not for transactional business data.

Validating before go-live

We run three checks on every LoongArch build before signing off: a 24-hour read/write soak test against openGauss at the target ingest rate, a failover drill to confirm the systemd units restart cleanly after a kill -9, and a dialect sweep that runs the full metadata query set against a scratch schema. The last one catches most surprises, because a query that returns correct results on x86 PostgreSQL can still behave differently once the openGauss optimizer and its older planner get hold of it.

Gotchas

• The 3A5000's per-core performance trails same-generation x86; keep agent regexes simple, as complex patterns can halve per-core throughput.
• Kylin V10 ships with the firewall on; open ports 5432 and OBSERVE's 8080, or the database won't connect.
• The LoongArch binary ecosystem is still catching up — dependency library versions may be older than x86, so the installer should use system libraries rather than forcing newer versions.
• Run a full regression on real LoongArch hardware before go-live; something that passed on x86 may simply not start on LoongArch.

Why we keep writing these

Each xinchuang combination — Kunpeng/Kylin/Dameng, Phytium/UOS/Kingbase, now Loongson/Kylin/openGauss — fails in a different place. The CPU decides the binaries you can run, the OS decides the firewall and locale, and the database decides the SQL dialect and write durability. The lesson isn't any single fix; it's that you cannot assume anything works until it has run on the exact combination you're shipping.