Three nodes buy fault tolerance and an operating job
CockroachDB's production guide says at least 3 nodes are needed to tolerate 1 node failure with the default replication factor. Each node should run on a separate machine, because several processes on one host leave that host as a single point of failure. The database then spreads strongly consistent SQL data across those nodes and rebalances it as the cluster changes. That is useful infrastructure when losing a machine cannot mean losing the database.
The trade is visible in the source tree. Our commit 6079877 checkout contained 25,505 files, roughly 4,700,432 lines of source, and occupied 636.5 MB before installation. CockroachDB includes a transactional key-value layer, SQL execution, replication, rebalancing, backup, change feeds, and operational tooling in one repository. A small application that only needs one dependable SQL server would inherit a large system while using little of the reason it exists.
A 37-second build is the easy part of self-hosting
Our sandbox built CockroachDB in 37 seconds after a 183-second install pulled 1,167 packages. The README still directs ordinary users toward a prebuilt executable or Cockroach Cloud, while source builders go to a separate development wiki. That split makes sense. Compiling one binary in an 8 GB container proves much less than running a secure cluster through upgrades, node loss, backup restoration, and application traffic.
Production setup reaches well beyond a connection string. The official checklist calls for TLS certificates for the certificate authority, every node, and each client or user. Operators also choose stable listen and advertised addresses, locality labels, storage, memory, load balancing, and monitoring. The same guide recommends matching hardware and operating systems across nodes. CockroachDB automates data placement, but your team still owns the machines and the failure drills.
What happened when we ran it
Our fresh Debian sandbox installed 1,167 Go packages in 183 seconds, then completed the build in 37 seconds. We used 3 CPUs, 8 GB of RAM, the golang:1.24-bookworm image, no secrets, and an unprivileged container. The 636.5 MB checkout had 27 CI workflow files, no Dockerfile, and no dedicated tests directory. Install and build both returned success.
The test step returned exit code 1 after 396 seconds. Go test reported 100 passed and 1,026 failed out of 1,126. The log tail lists roachmart, tpcc, tpcds, tpch, ycsb, and other workload packages as build failures before the final FAIL. Those lines do not identify the underlying error, so we cannot say whether code, missing system software, generated files, or another prerequisite caused it.
That result does not mean 1,026 database behaviors were proven wrong. It means the repository-wide command did not produce a clean test signal in the stated container. For an adoption trial, use the documented binary or cloud path first, then test your schema, transactions, failover, and restore procedure. Contributors should reproduce the source build with CockroachDB's own development instructions rather than treating our generic 396-second run as a diagnosis.
Version 24.3 and later use a production license key
The README says the CockroachDB Software License applies to major series v24.3 and later, plus named patches in earlier series. Its terms allow operation without a key only for limited non-production use or a database running solely on 1 node. Multi-node production therefore involves a key from Cockroach Labs. The license also says the software sends telemetry and allows disabling it only when the issued key permits that choice.
Those conditions make CockroachDB source-available, but they do not give an operator the same freedom as a permissive database license. A company with rules against mandatory telemetry or vendor-issued runtime keys should settle the contract before a technical proof of concept. The same caution applies to modified builds because the license requires protective measures to remain. A passed 37-second build does not change the permission to run the result.
Open v26.2.6 reports deserve workload-specific regression tests
Issue 175540 reports a narrow wrong-result case on v26.2.6 and v26.3.1. With vectorized execution off, a partially ordered query using LIMIT 5 OFFSET 100 returned 105 rows in the reporter's reproduction. The issue was open and triaged on September 16, 2026. Teams using pagination should add that query shape to acceptance tests, especially if support has advised disabling vectorized execution for another problem.
Issue 173047 covers different hardware. Its reporter could run all-amd64 and all-s390x clusters on v26.2.5, but an s390x node joining an amd64 cluster crashed while deserializing an Arrow batch. Turning off vectorized execution let the node join, at a stated performance cost. Neither report describes every deployment. Both show why PostgreSQL wire compatibility and a successful 37-second compile are starting points, not substitutes for testing the exact topology and SQL paths you plan to use.
September 16 activity is high despite an empty release endpoint
The repository was pushed on September 16, 2026, and GitHub showed 32,531 stars. A separate search found 7,395 open issues and 1,018 open pull requests, with automated test failures and user bug reports updated the same day. That queue is noisy, but the dated activity rules out the idea that the project is dormant. It also gives evaluators a large public record to search for their query and hardware patterns.
GitHub's latest-release endpoint returned no release record, while the tags list began with v26.2.6. Use CockroachDB's documented release and download channels rather than reading the empty endpoint as abandonment. The decision comes back to need: if 3-node failure tolerance and distributed SQL solve a real business constraint, the operational cost may be justified. If they do not, PostgreSQL leaves your team with far less machinery to own.