<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/3-hours-to-7-minutes-fixing-aurora-postgresql-s-silent-create-database-regression-ea1iig0ij" -->

---
title: 3 Hours to 7 Minutes: Fixing Aurora PostgreSQL’s Silent...
description: A database engineer managing 30+ Kubernetes clusters discovered that upgrading Aurora PostgreSQL from PG14/15 to PG16 silently changed the default CREATE...
canonical: https://daily.dev/posts/3-hours-to-7-minutes-fixing-aurora-postgresql-s-silent-create-database-regression-ea1iig0ij
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: 3 Hours to 7 Minutes: Fixing Aurora PostgreSQL’s Silent CREATE DATABASE Regression | daily.dev
og:description: A database engineer managing 30+ Kubernetes clusters discovered that upgrading Aurora PostgreSQL from PG14/15 to PG16 silently changed the default CREATE...
og:url: https://daily.dev/posts/3-hours-to-7-minutes-fixing-aurora-postgresql-s-silent-create-database-regression-ea1iig0ij
og:image: https://api.daily.dev/og/posts/ea1iiG0ij.png
og:image:alt: 3 Hours to 7 Minutes: Fixing Aurora PostgreSQL’s Silent CREATE DATABASE Regression
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 3 Hours to 7 Minutes: Fixing Aurora PostgreSQL’s Silent CREATE DATABASE Regression

**[Medium](https://daily.dev/sources/medium_js)** · 6 min read · 0 upvotes · 0 comments

## Summary

A database engineer managing 30+ Kubernetes clusters discovered that upgrading Aurora PostgreSQL from PG14/15 to PG16 silently changed the default CREATE DATABASE strategy from FILE_COPY to WAL_LOG (a change introduced in PG15). This caused database cloning jobs to balloon from 7 minutes to 3 hours with no errors or warnings. WAL_LOG clones block-by-block through the write-ahead log at ~8 MB/s on Aurora, while FILE_COPY works at the filesystem level and scales with Aurora's storage throughput. The fix is a single SQL clause: STRATEGY = FILE_COPY. Benchmarks showed 22-26x speedups on production databases ranging from 13 GB to 87 GB. AWS has not documented this behavioral change anywhere.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://medium.com/@ajo/3-hours-to-7-minutes-fixing-aurora-postgresqls-silent-create-database-regression-4f8516facee0>

## Questions this post answers

### Why did my CREATE DATABASE WITH TEMPLATE clone suddenly get much slower after upgrading Aurora PostgreSQL to PG16?

PostgreSQL 15 silently changed the default clone strategy for CREATE DATABASE ... WITH TEMPLATE from FILE_COPY to WAL_LOG. WAL_LOG reads and rewrites every block through the write-ahead log at a roughly flat 8 MB/s regardless of instance size or ACUs, while the old FILE_COPY default worked at the filesystem level and scaled with Aurora's storage throughput, causing multi-hour clones instead of minutes.

_daily.dev helps engineers tracking down Aurora and Postgres upgrade regressions like this one stay current._

### How do I fix slow database cloning on Aurora PostgreSQL after upgrading past PG15?

Add STRATEGY = FILE_COPY to the CREATE DATABASE ... WITH TEMPLATE statement to restore the old fast clone behavior. This single clause works as far back as PG15 and produced 22x to 26x speedups in testing, for example turning an 87 GB clone from about 3 hours into under 7 minutes on Aurora PostgreSQL 16.11.

_Teams pinning down Aurora performance regressions can follow fixes like this on daily.dev._

### Is PostgreSQL 18's file_copy_method = clone feature the same as the STRATEGY = FILE_COPY option for CREATE DATABASE?

No, they are unrelated features. STRATEGY = FILE_COPY is a CREATE DATABASE clone strategy available since PG15 that works on Aurora, while file_copy_method = clone is a PG18 instant copy-on-write cloning feature that requires a copy-on-write filesystem, which Aurora does not expose, making it unsupported there.

_Engineers evaluating Postgres version upgrades can track these distinctions via daily.dev._

## Similar posts on daily.dev

- [All Your GUCs in a Row: file\_copy\_method](https://daily.dev/posts/all-your-gucs-in-a-row-file-copy-method-plrdeoars) · Planet PostgreSQL · 1 upvotes · 0 comments
- [Migrating mission-critical payments at Nubank to Amazon Aurora PostgreSQL](https://daily.dev/posts/migrating-mission-critical-payments-at-nubank-to-amazon-aurora-postgresql-uhkwmxh9s) · AWS Database Blog · 5 upvotes · 0 comments

---

Tags: [#aws](https://daily.dev/tags/aws), [#kubernetes](https://daily.dev/tags/kubernetes), [#backend](https://daily.dev/tags/backend), [#postgresql](https://daily.dev/tags/postgresql)

[View this post on daily.dev](https://daily.dev/posts/3-hours-to-7-minutes-fixing-aurora-postgresql-s-silent-create-database-regression-ea1iig0ij)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"3 Hours to 7 Minutes: Fixing Aurora PostgreSQL’s Silent CREATE DATABASE Regression","url":"https://daily.dev/posts/3-hours-to-7-minutes-fixing-aurora-postgresql-s-silent-create-database-regression-ea1iig0ij","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/3-hours-to-7-minutes-fixing-aurora-postgresql-s-silent-create-database-regression-ea1iig0ij"},"datePublished":"2026-07-18T19:31:21.928Z","dateModified":"2026-09-13T21:41:29.858Z","description":"A database engineer managing 30+ Kubernetes clusters discovered that upgrading Aurora PostgreSQL from PG14/15 to PG16 silently changed the default CREATE...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/12cf229eee190f546d658e3c007c8d2c?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/12cf229eee190f546d658e3c007c8d2c?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/3-hours-to-7-minutes-fixing-aurora-postgresql-s-silent-create-database-regression-ea1iig0ij","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"aws,kubernetes,backend,postgresql","timeRequired":"PT6M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"3 Hours to 7 Minutes: Fixing Aurora PostgreSQL’s Silent CREATE DATABASE Regression"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/3-hours-to-7-minutes-fixing-aurora-postgresql-s-silent-create-database-regression-ea1iig0ij#faq","mainEntity":[{"@type":"Question","name":"Why did my CREATE DATABASE WITH TEMPLATE clone suddenly get much slower after upgrading Aurora PostgreSQL to PG16?","acceptedAnswer":{"@type":"Answer","text":"PostgreSQL 15 silently changed the default clone strategy for CREATE DATABASE ... WITH TEMPLATE from FILE_COPY to WAL_LOG. WAL_LOG reads and rewrites every block through the write-ahead log at a roughly flat 8 MB/s regardless of instance size or ACUs, while the old FILE_COPY default worked at the filesystem level and scaled with Aurora's storage throughput, causing multi-hour clones instead of minutes. daily.dev helps engineers tracking down Aurora and Postgres upgrade regressions like this one stay current."}},{"@type":"Question","name":"How do I fix slow database cloning on Aurora PostgreSQL after upgrading past PG15?","acceptedAnswer":{"@type":"Answer","text":"Add STRATEGY = FILE_COPY to the CREATE DATABASE ... WITH TEMPLATE statement to restore the old fast clone behavior. This single clause works as far back as PG15 and produced 22x to 26x speedups in testing, for example turning an 87 GB clone from about 3 hours into under 7 minutes on Aurora PostgreSQL 16.11. Teams pinning down Aurora performance regressions can follow fixes like this on daily.dev."}},{"@type":"Question","name":"Is PostgreSQL 18's file_copy_method = clone feature the same as the STRATEGY = FILE_COPY option for CREATE DATABASE?","acceptedAnswer":{"@type":"Answer","text":"No, they are unrelated features. STRATEGY = FILE_COPY is a CREATE DATABASE clone strategy available since PG15 that works on Aurora, while file_copy_method = clone is a PG18 instant copy-on-write cloning feature that requires a copy-on-write filesystem, which Aurora does not expose, making it unsupported there. Engineers evaluating Postgres version upgrades can track these distinctions via daily.dev."}}]}
```

