Live data from Hacker News

Database Lab – Full-size staging databases as a service

gitlab.com

11–20 of 32 posts

Re: Database Lab – Full-size staging databases as a service

#12
post #8

Earlier quoted context omitted.

It doesn't appear to be able to at this point, no. Just clones the existing DB. There are masking tools out there that can mask data from production in-flight before dropping it into a dev environment for testing (so you can get the same data with the sensitive parts changed), but this doesn't appear to be one of them. I know people who work in the field, it's a tough nut to crack to keep the database good enough to…

> There are masking tools out there that can mask data from production Thank you so much! "Masking" was the phrase I needed to find some potential solutions! I wasn't able to find much before, that points me in the correct direction. Thanks!

Other common terms for this are sanitization or redaction

Re: Database Lab – Full-size staging databases as a service

#13
post #5

This looks like open source Delphix using Postgres. It even seems to be using ZFS under the hood. Any comments from people using it? I designed a CI system using Delphix at an old client and it was awesome!

Also curious what the performance is like?

We switched our staging databases to be on ZFS and saw inexplicable, very noticeable decreases in performance. Those trade-offs are fine for developer machines, but ultimately too much for our staging server where we needed to run UAT.

But, could of just been quirks of how we had things set up.

Re: Database Lab – Full-size staging databases as a service

#14
post #10
post #4

Question: Can this clone a database, but also apply certain operations to it? I work at a small company, and currently we clone our production database to our dev machines for testing. However certain information in the database is sensitive and we don't want to include it on our dev machines. (This specific sensitive data is also stored in an encrypted format and the key is not included, but we'd still prefer it not…

If you're willing to pay for it Delphix would do what you want. I've not used those features but their tech guys were describing that very scenario in a presentation I saw.

Our company is pretty small (We only have 5 developers) and judging by the lack of pricing info (you can only request a demo) - I'm guessing it's too expensive for us haha.

But thanks for the suggestion!

Re: Database Lab – Full-size staging databases as a service

#15
post #4

Question: Can this clone a database, but also apply certain operations to it? I work at a small company, and currently we clone our production database to our dev machines for testing. However certain information in the database is sensitive and we don't want to include it on our dev machines. (This specific sensitive data is also stored in an encrypted format and the key is not included, but we'd still prefer it not…

Hi! Postgres.ai founder here.

This is requested quite often – for example, if we copy the database from production, sometimes it's needed to remove all personal data not to break regulations.

It is possible in Database Lab, but it's not a very user-friendly feature yet. Briefly, the process is as follows.

The "sync" Postgres instance is configured to be a production replica (better using WAL shipping from the WAL archive). Then, periodically, a new snapshot is created, currently it's done using this Bash script: https://gitlab.com/postgres-ai/database-lab/-/blob/master/sc.... (We are going to make it a part of the database-lab server in the upcoming releases).

Here https://gitlab.com/postgres-ai/database-lab/-/blob/master/sc... you can place any data transformations, so the final snapshot that will be used for thin cloning has adjusted data sets. For example, all personal data is removed or obfuscated.

Of course, if you do this, you need to keep in mind that physically, you'll have a different database. It may affect some kinds of testing (for example, troubleshooting bloat issues or some cases of index performance degradation). There are various choices to be made here. If interested, we'll be happy to help, please join our community Slack which is mentioned in the docs and README.

Re: Database Lab – Full-size staging databases as a service

#16
post #8

Earlier quoted context omitted.

It doesn't appear to be able to at this point, no. Just clones the existing DB. There are masking tools out there that can mask data from production in-flight before dropping it into a dev environment for testing (so you can get the same data with the sensitive parts changed), but this doesn't appear to be one of them. I know people who work in the field, it's a tough nut to crack to keep the database good enough to…

> There are masking tools out there that can mask data from production Thank you so much! "Masking" was the phrase I needed to find some potential solutions! I wasn't able to find much before, that points me in the correct direction. Thanks!

There are various approaches here, and there are some FOSS tools that you can use.

Some links:

- https://blog.taadeem.net/english/2019/01/03/8_anonymization_... – description of methods, and a tool for Postgres, postgresql_anonymizer

- https://habr.com/en/company/yandex/blog/485096/ – not for Postgres, it's for ClickHouse (open-source DBMS for analytics) but covers the topic very well.

Re: Database Lab – Full-size staging databases as a service

#17

Love the idea, but is this essentially then just a faster version of pg_dump ? pg_dump -C -h remotehost -U remoteuser dbname | psql -h localhost -U localuser dbname

Well, not really. Two key differences:

1) dump/restore approach is one of "thick cloning" methods. It will take a really significant amount of time. Roughly, thick cloning speed for modern hardware and networks is somewhat ~1 TiB / hour just for transferring over network and writing to disk. Additionally, in the case of dump/restore, the timing will depend on the number of indexes that need to be built, materialized views to be refreshed, etc.

2) Dump/restore is "logical copying", it means that physical structure is not preserved. Logically, you'll get the same data. Physically – a completely different database. Bloat is gone, indexes are "fresh and good", and so on.

With Database Lab, unless you're on RDS, initial copying is preferably done using some "physical" methods (pg_basebackup, or just rsync, or – the best option – restoration from WAL-G/pgBackRest/Barman/etc backups). The physical structure is preserved. You have an identical copy of the original database. Then you request "thin clones", it really takes a couple of seconds for a multi-terabyte database. And can do various kinds of performance troubleshooting and experiments before you deploy your changes to production. Request 5 thin clones and check your idea 5 times, each time adjusting it a little bit. This is what usually really needed in development.

Re: Database Lab – Full-size staging databases as a service

#18

Love the idea, but is this essentially then just a faster version of pg_dump ? pg_dump -C -h remotehost -U remoteuser dbname | psql -h localhost -U localuser dbname

Well, not really. Two key differences: 1) dump/restore approach is one of "thick cloning" methods. It will take a really significant amount of time. Roughly, thick cloning speed for modern hardware and networks is somewhat ~1 TiB / hour just for transferring over network and writing to disk. Additionally, in the case of dump/restore, the timing will depend on the number of indexes that need to be built, materialized…

Ahh okay, that makes sense. I wasn't aware that using different methods of copying + backing up data had tangible effects on it later. Super interesting, and vital if you're looking to gather accurate data from experiments.

By the way, I recognized you guys from the other tool you publish, Nancy. While I don't have a direct usecase for it myself, I thought the idea was super valuable as well.

I am a huge Postgres guy (did you know you can build an entire web app in JUST Postgres?[0]) so I had bookmarked a couple of your projects.

Thank you for the response, you guys do some fantastic work.

[0]: https://github.com/aquametalabs/aquameta

Re: Database Lab – Full-size staging databases as a service

#19

Love the idea, but is this essentially then just a faster version of pg_dump ? pg_dump -C -h remotehost -U remoteuser dbname | psql -h localhost -U localuser dbname

Well, not really. Two key differences: 1) dump/restore approach is one of "thick cloning" methods. It will take a really significant amount of time. Roughly, thick cloning speed for modern hardware and networks is somewhat ~1 TiB / hour just for transferring over network and writing to disk. Additionally, in the case of dump/restore, the timing will depend on the number of indexes that need to be built, materialized…

Can you explain what a thin clone is?

Re: Database Lab – Full-size staging databases as a service

#20
post #9
post #6

Earlier quoted context omitted.

I saw them contributing often to ZFS on FreeBSD, what is their product? Is it equivalent to NetApp?

Not seen NetApp but from a quick Google it seems to be more intelligent database management. Delphix is more using the power of ZFS and Copy On Write to give you instant database copies with minimal storage footprint. We used it to give every developer their own Database that they could do anything to and not worry about locks etc. Refreshing to a more recent copy was a very quick operation and required a developer r…

Ah, so this indeed looks like Open Source version of Delphix.

As for NetApp, probably the do other things but most popular is their NAS which internally uses Copy On Write filesystem similar to ZFS.

Post reply on HN