Live data from Hacker News

Instant database clones with PostgreSQL 18

boringsql.com

11–20 of 168 posts

Re: Instant database clones with PostgreSQL 18

#11
post #5

It looks very interesting for integration tests

would this work inside test containers?

OP here - still have to try (generally operate on VM/bare metal level); but my understanding is that ioctl call would get passed to the underlying volume; i.e. you would have to mount volume

Re: Instant database clones with PostgreSQL 18

#12
In theory, a database that uses immutable data structures (the hash array mapped trie popularized by Clojure) could allow instant clones on any filesystem, not just ZFS/XFS, and allow instant clones of any subset of the data, not just the entire db. I say "in theory" but I actually built this already so it's not just a theory. I never understood why there aren't more HAMT based databases.

Re: Instant database clones with PostgreSQL 18

#13
Uff, I had no idea that Postgres v15 introduced WAL_LOG and changed the defaults from FILE_COPY. For (parallel CI) test envs, it make so much sense to switch back to the FILE_COPY strategy ... and I previously actually relied on that behavior.

Raised an issue in my previous pet project for doing concurrent integration tests with real PostgreSQL DBs (https://github.com/allaboutapps/integresql) as well.

Re: Instant database clones with PostgreSQL 18

#14
post #10

For anyone looking for a simple GUI for local testing/development of Postgres based applications. I built a tool a few years ago that simplifies the process: https://github.com/BenjaminFaal/pgtt

Would love to see a snapshot of the GUI as part of the README.md. Also docker link seems to be broken.

Fixed the package link. Github somehow made it private. I will add a snapshot right now.

Re: Instant database clones with PostgreSQL 18

#16
post #4

aws supports this as well: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

Aurora clones are copy-on-write at the storage layer, which solves part of the problem, but RDS still provisions you a new cluster with its own endpoints, etc, which is slow ~10 mins, so not really practical for the integration testing use case.

Re: Instant database clones with PostgreSQL 18

#17
For those who can't wait for PG18 or need full instance isolation: I built Velo, which does instant branching using ZFS snapshots instead of reflinks.

Works with any PG version today. Each branch is a fully isolated PostgreSQL container with its own port. ~2-5 seconds for a 100GB database.

https://github.com/elitan/velo

Main difference from PG18's approach: you get complete server isolation (useful for testing migrations, different PG configs, etc.) rather than databases sharing one instance.

Re: Instant database clones with PostgreSQL 18

#19
post #17

For those who can't wait for PG18 or need full instance isolation: I built Velo, which does instant branching using ZFS snapshots instead of reflinks. Works with any PG version today. Each branch is a fully isolated PostgreSQL container with its own port. ~2-5 seconds for a 100GB database. https://github.com/elitan/velo Main difference from PG18's approach: you get complete server isolation (useful for testing migrat…

[flagged]

Re: Instant database clones with PostgreSQL 18

#20

In theory, a database that uses immutable data structures (the hash array mapped trie popularized by Clojure) could allow instant clones on any filesystem, not just ZFS/XFS, and allow instant clones of any subset of the data, not just the entire db. I say "in theory" but I actually built this already so it's not just a theory. I never understood why there aren't more HAMT based databases.

This is typical for analytical databases, e.g., ClickHouse (which I'm the author of) uses immutable data parts, allowing table cloning: https://clickhouse.com/docs/sql-reference/statements/create/...
Post reply on HN