Thin PostgreSQL Clones
github.com
Thin PostgreSQL Clones
1–10 of 37 posts
Re: Thin PostgreSQL Clones
#2It’s a tool that clones Postgres databases. It’s not a clone of Postgres the application.
Re: Thin PostgreSQL Clones
#3A little off topic, but you can convert simple text to PostgreSql scripts,
Re: Thin PostgreSQL Clones
#4A little off topic, but you can convert simple text to PostgreSql scripts, https://text2db.com/
Interesting.
How do you specify data types for columns or schema names for tables?
For modern Postgres versions it's also recommended to use standard compliant identity columns rather than the proprietary serial "types"
Re: Thin PostgreSQL Clones
#5Is 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.
Re: Thin PostgreSQL Clones
#6Is 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 think it will work well for verifying DB changes and optimizing SQL on real data.
This seems like a great tool to eliminate the risk of database-related downtime.
Re: Thin PostgreSQL Clones
#7Is 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 think it will work well for verifying DB changes and optimizing SQL on real data. This seems like a great tool to eliminate the risk of database-related downtime.
It is, but it introduces new risks. Like your test code emailing all of your production users. And more generally data security issues.
Re: Thin PostgreSQL Clones
#8Is 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.
You can clone the "depersonalized" data for your developer teammates
in a team: 10 developers working on 32 issues: --> need at least 32 separated environments.
Re: Thin PostgreSQL Clones
#9Earlier quoted context omitted.
I think it will work well for verifying DB changes and optimizing SQL on real data. This seems like a great tool to eliminate the risk of database-related downtime.
It is, but it introduces new risks. Like your test code emailing all of your production users. And more generally data security issues.
You are absolutely right. Depending on the current environment, you should think about the protection of sensitive data (for example, data masking and obfuscation, access control).
Database Lab Engine provides some possible solutions to protect sensitive data: https://postgres.ai/docs/database-lab/masking
By the way, the Database Lab Engine maintainer is here.
Re: Thin PostgreSQL Clones
#10Is 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 if you have huge amounts of data.