Live data from Hacker News

Thin PostgreSQL Clones

github.com

11–20 of 37 posts

Re: Thin PostgreSQL Clones

#11
post #5

Is this advocating the use of production data in dev/test/qa environments? I am struggling to come up with scenarios where that would be a good idea.

Not sure about webapps but in analytics, this is a common practice. Real data has too many exceptions and edge cases. If you dont develop and test with real data, you will end up effectively developing or testing on production.

Re: Thin PostgreSQL Clones

#12
post #10
post #5

Is this advocating the use of production data in dev/test/qa environments? I am struggling to come up with scenarios where that would be a good idea.

I have always made clones of production data on my dev machine for testing -- it has the added benefit of also regularly testing my DB backup restoration process. How else do you test and optimize SQL queries that are only slow with production-size data? If the data is too big to fit on my machine, I might clone to a nearby colocated server. Testing your DB backup and restoration mechanism becomes even MORE important…

> How else do you test and optimize SQL queries that are only slow with production-size data?

With something like this https://www.getsynth.com/docs/blog/2021/03/09/postgres-data-... (disclaimer: no affiliation with them, I've not used their product but it appears to be fully open source)

Re: Thin PostgreSQL Clones

#13
post #10

Earlier quoted context omitted.

I have always made clones of production data on my dev machine for testing -- it has the added benefit of also regularly testing my DB backup restoration process. How else do you test and optimize SQL queries that are only slow with production-size data? If the data is too big to fit on my machine, I might clone to a nearby colocated server. Testing your DB backup and restoration mechanism becomes even MORE important…

> How else do you test and optimize SQL queries that are only slow with production-size data? With something like this https://www.getsynth.com/docs/blog/2021/03/09/postgres-data-... (disclaimer: no affiliation with them, I've not used their product but it appears to be fully open source)

I agree that this is a possible way. The main difficulty of the generated data is related to their quality and structure. Namely, how artificial data correspond (quantitatively and qualitatively) to real data.

Random data may give incorrect results when optimizing a query.

Re: Thin PostgreSQL Clones

#14
This looks like a really useful tool for staging and development environments, and it's even OSS that can be self-hosted! Does anybody here have any real-life experiences with it they could to share?

Re: Thin PostgreSQL Clones

#16
post #14

This looks like a really useful tool for staging and development environments, and it's even OSS that can be self-hosted! Does anybody here have any real-life experiences with it they could to share?

There are several public Case Studies of real users (from small teams to quite large companies): https://postgres.ai/resources/

For more real-life feedback, welcome to the Database Lab Community Slack: https://slack.postgres.ai/

Re: Thin PostgreSQL Clones

#18
post #11
post #5

Is this advocating the use of production data in dev/test/qa environments? I am struggling to come up with scenarios where that would be a good idea.

Not sure about webapps but in analytics, this is a common practice. Real data has too many exceptions and edge cases. If you dont develop and test with real data, you will end up effectively developing or testing on production.

Absolutely agreed. In addition, I know some Data Scientists who use thin clones from Database Lab to get data at a specific time for their models

Re: Thin PostgreSQL Clones

#19
If you're interested how it works (and how to possibly implement it by yourself), I wrote about the idea a few years ago. [1] To Postgres, recovering as a clone looks the same as if someone suddenly unplugged the computer power cable.

The shell script that implements the idea with LVM snapshots (relies on an existing Postgres physical replica) is not too long. It's used over SSH.

    $ wc -l /usr/local/bin/snapshot-*
     164 /usr/local/bin/snapshot-create
      16 /usr/local/bin/snapshot-drop
     180 total
Had this tool existed at the time, I'd have probably used it (monitoring and REST API might be handy). Still, the core idea can be implemented very easily.

[1]: https://www.sedlakovi.org/blog/2019/03/fast-postgres-snapsho...

Re: Thin PostgreSQL Clones

#20
I'm doing something similar by cloning the data directory using BTRFS snapshots for backups and testing, apart from the UI is there a reason why this tool might be worth looking at?
Post reply on HN