CockroachDB

CockroachDB speaks the PostgreSQL wire protocol, so AddisDB drives it with the Postgres driver — but monitoring is written specifically for Cockroach, reading its crdb_internal tables instead of the pg_stat_* views it does not fully implement.

Who it is for

CockroachDB is for teams that need a SQL database to survive the loss of a node, a zone, or an entire region without a failover runbook. It replicates and rebalances automatically, keeps strong consistency, and lets you pin data to geographies for latency or residency reasons.

The mechanism is worth understanding because it explains the trade-offs: data is split into ranges, each range is replicated an odd number of times, and every write is agreed by a Raft quorum. Consensus across machines is what makes a node loss a non-event — and also what makes a single write slower than on a single-node database.

Use it when uptime and multi-region are hard requirements and you would rather not re-architect around eventual consistency. Skip it if you have one region and no availability pressure — plain Postgres will be simpler and faster.

Set up the cluster

1. On CockroachDB Cloud, create a cluster, then open Connect and choose the "General connection string" option.
2. Create a SQL user and copy the generated password — the console shows it once.
3. Download the CA certificate if the console offers one, and note that the cluster requires a verified TLS connection.
4. Add your IP to the cluster’s allowlist under Networking.
5. Self-hosted: cockroach start-single-node --insecure --listen-addr=localhost:26257 is enough for local work.

# A local single node, with the DB console on 8080
cockroach start-single-node --insecure \
  --listen-addr=localhost:26257 --http-addr=localhost:8080

Connect from AddisDB

1. New Connection → CockroachDB. Port prefills to 26257 and the database to defaultdb.
2. Paste the connection string from the Cockroach console into the Connection URL box and click Fill fields — it carries the user, cluster host and database for you.
3. Set SSL mode to verify-full for CockroachDB Cloud, or disable for an insecure local node.
4. Serverless clusters put a routing id in the options parameter of the URL. Use Fill fields rather than retyping the host, so that part is not lost.
5. Test, then Save.

Where it differs from PostgreSQL

Cockroach is wire-compatible, not behaviour-identical, and the differences are the interesting part of using it.

• Transactions run at SERIALIZABLE by default, so a contended transaction can come back with a 40001 retry error. That is not a failure — the client is expected to retry it.
• Sequential primary keys create a hotspot on one range. UUIDs, or the built-in unique_rowid(), spread writes across the cluster.
• AS OF SYSTEM TIME lets a read run slightly in the past against a nearby replica, which turns a cross-region read into a local one.
• SHOW RANGES tells you where data physically lives — the question that has no equivalent on a single-node database.
• Some Postgres extensions and catalog corners simply do not exist; introspection is written to tolerate that rather than fail the refresh.

What AddisDB gives you

• Full schema introspection and the foreign-key diagram, same as Postgres.
• In-grid editing of cells and rows behind the Edit toggle.
• Live Monitor built on crdb_internal — active statements and sessions, read through Cockroach’s own catalog rather than a Postgres impersonation.
• Mock data generated from your real schema.
• Plain-English querying and one-click fixes for failing SQL.
• Read-only connections, prod tagging and destructive-statement detection.