CockroachDB requires explicit users as password authentication arrives
The November beta adds password authentication over the PostgreSQL wire protocol. Secure connections now require an explicitly created SQL user, including when they use certificates.
A client certificate can establish an identity without answering whether that identity exists as a database user. CockroachDB's November 3 beta tightens that relationship while introducing password authentication. Except for root, users must now be created explicitly before they can authenticate through either a TLS certificate or a password. The change makes database user creation part of secure connection provisioning.
The contemporary beta notes classify this as a backwards-incompatible change. Existing certificate-based setups need attention even if they have no interest in passwords. The new requirement is attached to the recognized SQL identity, so it affects both documented secure authentication routes.
I find PostgreSQL wire compatibility useful because it lets a distributed SQL database meet clients where they already are. Authentication is part of that compatibility, alongside query messages. It needs an explicit account model so familiar connection mechanisms do not obscure which identities the server recognizes.
User creation becomes a prerequisite
The notes identify CREATE USER and cockroach user set as the ways to create the user. A certificate alone no longer supplies the entire setup for a non-root identity. Provisioning must arrange both the authentication material and the corresponding database user before the connection can succeed.
This is a meaningful ordering requirement. A system can successfully generate or distribute a certificate while the database still has no user to authenticate under the new rule. Treating those as separate steps gives a precise explanation for a connection failure during rollout. Completing the certificate step does not establish completion of SQL user provisioning.
The implementation pull request, merged November 1, describes adding CREATE USER and password-based authentication for pgwire connections together. That implementation work supports both the account-creation mechanism and the new authentication option. This beta makes them available together.
The exception for root is explicit in the notes. It should not be generalized into a claim that every existing name is automatically recognized, or that certificate-based users are exempt. For ordinary non-root identities, the creation requirement is the stated compatibility change.
Passwords extend the connection options
Clients can now authenticate with a TLS certificate or a password. This extends the available proof of identity without removing the certificate option. The notes say further documentation is forthcoming, so the release announcement alone is not a complete reference for deployment or password-management procedures.
That limitation matters when introducing examples. A familiar PostgreSQL command or connection option should not be assumed to have identical CockroachDB behavior merely because the client speaks pgwire. The verified change is support for password authentication and explicit user creation. Operational details need the corresponding CockroachDB interface documentation.
Password support can make the database accessible to clients whose existing integration expects that authentication method. Certificate support remains useful for deployments built around client certificates. Both routes now converge on the requirement that the SQL identity exist, giving account provisioning a common place in the connection model.
I prefer that common requirement to an account lifecycle that changes implicitly with the authentication method. A deployment can reason about the database user separately from the credential used to prove that user's identity. The beta's compatibility warning identifies exactly where existing provisioning must change.
Compatibility also includes schema inspection
The beta adds several PostgreSQL catalogue tables, including pg_type, pg_database, pg_views, pg_proc, and pg_am. It also adds information_schema.statistics and information_schema.views. These changes support clients that inspect database metadata before issuing application queries.
A wire-compatible connection is only the first step for such software. A tool may connect successfully and then ask for types, databases, or views using catalogue queries. Adding those relations addresses that later interaction. The release notes enumerate individual additions, which is more precise than a claim that PostgreSQL compatibility is complete.
SHOW USERS is also new, making recognized database users inspectable through SQL. Meanwhile, SHOW CREATE VIEW now requires permission on the view without also requiring permission on underlying tables. These changes concern distinct aspects of inspection, account visibility and the authority needed to inspect a view definition.
The built-in shell shortens interactive transaction lifetime
The same release changes the SQL shell to buffer statements after entering a transaction. It sends them when it reaches COMMIT, ROLLBACK, or two blank lines. The stated purpose is to minimize the transaction's lifetime and therefore the risk of conflicts.
This addresses time spent composing statements interactively. A person can pause between lines for much longer than the database needs to execute them. Buffering reduces how much of that pause becomes an active transaction. It is a client-shell behavior, distinct from a change to transaction isolation.
The beta also begins monitoring SQL query memory usage so an excessive query can fail instead of exhausting server memory. Together with explicit user creation, these changes give administrators more defined boundaries around connections and interactive work. For secure clients upgrading to this beta, the immediate migration requirement remains creation of every non-root SQL user before certificate or password authentication can use it.