Blog

PostgreSQL 19 is scheduled for general availability on November 19, 2026, one week after PostgreSQL 14 reaches end of life on November 12. From then on, servers on PostgreSQL 14 get no more security fixes. Versions 15 through 18 are still supported, but version 19 will be supported the longest, into late 2031.

This post covers what version 19 changes for security and the schema objects that block an upgrade to it, and how to use the week before GA to prepare with Atlas: scan your servers for their versions and CVEs, keep upgrade blockers out with schema rules, and apply the same schema, roles, and grants to the new instance from code.

On October 30, 2026, ClickHouse published CVE-2026-116366, an unauthenticated remote code execution vulnerability in ClickHouse Server. Under certain conditions, a user with network access to the server can run arbitrary code on it without logging in. ClickHouse rates it Critical, with a CVSS v4.0 score of 9.5.

ClickHouse Cloud and BYOC deployments are already patched. Self-managed servers are not, and finding every one of them across your environments is the hard part. Atlas can do that for you: atlas security scan now checks the server version of each ClickHouse server against the Atlas Security Graph, and reports every published CVE that affects it, this one included, along with the release that fixes it.

In a Snowflake medallion architecture, raw data lands in Bronze, which dbt cleans into Silver and shapes into Gold. dbt owns the two upper layers completely. Every dbt run recreates the tables and views its models define, from code that is versioned, reviewed, and tested.

The bronze layer those models stand on has no such owner. This post is about that layer, and giving Bronze a proper owner without disrupting your dbt project.

Hey everyone!

We just released Atlas Kubernetes Operator v0.8, which adds drift detection before and between deployments, security scanning for deployed databases, and a setting for controlling dev databases per resource:

• Pre-Apply Drift Check: policy.drift on an AtlasMigration checks the database for drift before pending migrations are applied, and can block the deployment.
• Scheduled Drift Checks: AtlasDriftCheck checks the database of an AtlasMigration for drift on an interval and reports the result through conditions and Kubernetes events.
• Security Scanning: AtlasSecurityScan scans a database for extensions affected by published CVEs, on a schedule or after a schema change, and grades the findings against a policy.
• Per-Resource Dev Database Prewarming: AtlasSchema and AtlasMigration accept prewarmDevDB, overriding the operator-wide default.

"Managing schema as code was the mindset we were looking for, and it was a perfect match with Atlas. It's able to support our database and others, which gives us flexibility going forward."

– Raunak Kathuria, VP of Engineering, Deriv

Company Background​

Deriv is one of the world's largest online brokers, and was recently named Best Fintech Broker (Global) at the 2026 Global Forex Awards. They offer CFDs and other derivatives on forex, stocks and indices, cryptocurrencies, commodities, and Derived Indices to millions of registered users across the globe.

The company runs on PostgreSQL across many schemas and databases, including multi-tenant setups, and relies on advanced features like views, functions, triggers, stored procedures, and row-level security. All of it operates under compliance requirements, including SOC 2, HIPAA, and PCI, that demand full audit trails on every change. Deriv's engineering teams also actively use AI agents in their development work.

If you've searched for "DACPAC for PostgreSQL," you already know the answer: there isn't one. DACPAC is a Microsoft file format, built into SQL Server Data Tools and deployed with SqlPackage, and it has no equivalent outside the SQL Server ecosystem. What you're actually looking for isn't the file format, it's the workflow: define the schema once, let the tool diff it against a live database, and deploy the result without hand-written migration scripts. Atlas gives you that workflow for PostgreSQL.

Anthropic recently published The AI-Native SDLC playbook, and it's the most concrete writeup I've seen discussing the effects of cheaper code generation on a delivery process, written by a company where AI authors 80% of merged code. If you run engineering at any scale, I suggest you read it.

It consists of six stages from Plan to Maintain that work in a loop rather than a linear chain of handoffs. Each stage commits an artifact that the next stage reads. The chain of commits is the audit trail. Humans stop reading every line and start judging intent and risk.

GitLab's CEO responded with the line that will likely outlive the playbook itself: "when implementation becomes abundant, trust becomes scarce."

Code is abundant now. Your data is not. An agent can regenerate your code in an afternoon, but it cannot regenerate the production state your company accumulated over years. The playbook's recovery model quietly assumes otherwise, which leads to our claim: the loop does not close at the database.

The database is the one stateful component in your infrastructure. It's where the history lives, and you cannot roll back history by redeploying an older version of it.

"Everybody should be using Atlas. If anyone is still trying to manage their database objects in some more traditional way, they really need to get on board and start using Atlas."

– Kevin Hochhalter, VP of IT Operations, Health in Tech

Company Background​

Health in Tech (Nasdaq: HIT) is an AI-driven insurtech company that automates and streamlines self-funded health insurance plans for small and medium-sized businesses. Through integrated platforms like its eDIYBS quoting engine and HI Card claims system, Health in Tech reduces administrative friction across underwriting, risk management, and network pricing workflows, letting brokers, carriers, and third-party administrators design, price, and bind customized health plans within minutes.

Hey everyone!

We're excited to announce Atlas v1.3. This release delivers on a promise we made in v1.2: the security graph is now live in Atlas Cloud, mapping your entire database attack surface. It also introduces Atlas Scripts for running data operations as code, safer and faster migrations, and a new command group for working with the Atlas Registry from the CLI.

Here is what you can find in this release:

• Security Graph for Databases - Map your entire database attack surface: permissions, misconfigurations, and CVEs across every object, with severity tiers and blast-radius tracing.
• Atlas Scripts: DataOps as Code - Backfills, GDPR purges, and reports declared as code: transactional mutations, masked queries, and batched loops, reviewed and tested in CI.
• atlas cloud: Manage Registry Resources from the CLI - Repositories, databases, and deployment history from the terminal, with JSON output for scripts, CI gates, and AI agents, plus security graph and lineage graph exports.
• Schema Annotations - Attach type-safe metadata to schema resources and render GraphQL, OpenAPI, or any other format from it with templates.
• Pre-Apply Drift Detection - Block a deployment when the database drifted from the expected state, with the diff printed before any statement runs.
• Database Driver Improvements - Lock-safe NOT NULL and 8x-10x faster schema tests on PostgreSQL, Oracle roles and storage, Snowflake Iceberg tables, ClickHouse row policies, and more.
• Simpler Licensing and No AI Training - One agreement replaces the separate EULA and SaaS terms, with a written commitment that we never train AI models on your data.

Company Background​

Aryon Security is a preventative cloud security platform that enforces security policies at the point of deployment, stopping misconfigurations before they ever reach production rather than flagging them after the fact. Acting as a source-agnostic gatekeeper across AWS, Azure, and GCP, Aryon applies the same protection whether infrastructure is provisioned through IaC, ClickOps, or third-party providers, letting security and platform teams define a policy once and ensure only compliant infrastructure is ever deployed.