Live data from Hacker News

Instant database clones with PostgreSQL 18

boringsql.com

91–100 of 168 posts

Re: Instant database clones with PostgreSQL 18

#91

Earlier quoted context omitted.

Let's say there is an architect and he also owns a construction company. This architect, then designs a building and gets it built from of his employees and contractors. In such cases the person says, I have built this building. People who found companies, say they have built companies. It's commonly accepted in our society. So even if Claude built for it for GP, as long as GP designed it, paid for tools (Claude) to…

What an outrageously bad analogy. Everyone involved in that building put their professional reputations and licenses on the line. If that building collapses, the people involved will lose their livelihoods and be held criminally liable. Meanwhile this vibe coded nonsense is provided “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. We don’t even know if he read it before committing and pushing.

Same with any OSS. Up to you to validate whether or not it is worth depending on, regardless of how built. Social proof is a primary avenue to that and has little to do with how built.

Re: Instant database clones with PostgreSQL 18

#92
post #82

Earlier quoted context omitted.

> a Brazilian invented the airplane lol, good one!

wasn't it? last I checked, Wright brothers used a catapult while Santos-Dumont made a plane that took off by itself.

I think it was the Wright brothers taking off from level ground while Santos-Dumpont got something flying off a cliff earlier.

Re: Instant database clones with PostgreSQL 18

#93
post #55

Earlier quoted context omitted.

There was a recent wave of such comment on the rust subreddit - exactly in this shape "Oh you mean you built this with AI". This is highly toxic, lead to no discussion, and is literally drove by some dark thought from the commentator. I really hope HN will not jump on this bandwagon and will focus instead on creating cool stuff. Everybody in the industry is vibecoding right now - the things that stick are due to suff…

>This is highly toxic, lead to no discussion Why good faith is a requirement for commenting but not for submissions? I would argue the good faith assumption should be disproportionately more important for submissions given the 1 to many relationship. You're not lying, it indeed is toxic and rapidly spreading. I'm glad this is the case. Most came here for the discussion and enlightenment to be bombarded by heavily bia…

Your bias is that you think that because you can use a bike then my bike efforts are worthless. Considering that I often thrash out what I generate and I know I do not generate -> ship ; but have a quality process that validate my work by itself - the way I'm reaching my goals present no value to my public.

The reason this discussion is pathetic, is that it shifts the discussion from the main topic (here it was a database implementation) - to abide by a reactionary emotive emulation with no grace or eloquence - that is mostly driven by pop culture at this point with a justification mostly shaping your ego.

There is no point in putting yourself above someone else just to justify your behavior - in fact it only tells me what kind of person you were in the first place - and as I said, this is not the kind of attitude that i'm looking up to.

Re: Instant database clones with PostgreSQL 18

#94
post #55

Earlier quoted context omitted.

You mean you told Claude a bunch of details and it built it for you? Mind you, I'm not saying it's bad per se. But shouldn't we be open and honest about this? I wonder if this is the new normal. Somebody says "I built Xyz" but then you realize it's vibe coded.

There was a recent wave of such comment on the rust subreddit - exactly in this shape "Oh you mean you built this with AI". This is highly toxic, lead to no discussion, and is literally drove by some dark thought from the commentator. I really hope HN will not jump on this bandwagon and will focus instead on creating cool stuff. Everybody in the industry is vibecoding right now - the things that stick are due to suff…

> Everybody in the industry is vibecoding right now

no ‘everybody’ is not. a lot of us are using zero LLMs and continuing to build (quality) software just fine

Re: Instant database clones with PostgreSQL 18

#95

Earlier quoted context omitted.

I agree that it's ultimately about the product. But here's the problem. Five years ago, when someone on here said, "I wrote this non-trivial software", the implication was that a highly motivated and competent software engineer put a lot of effort into making sure that the project meets a reasonable standard of quality and will probably put some effort into maintaining the project. Today, it does not necessarily impl…

We know. It is not difficult to tell them apart. Good taste is apparent and beauty is universal. The amount of care and attention someone put into a craft is universally appreciated. Also, I am 100% confident this comment was the output of a human process. We can tell. There is something more. It is obvious for those that have a soul.

We know if we make the effort to find out. But what we really want to know is not whether AI was used in the process of writing the software. What we want to know is whether it's worth checking out. That's what has become harder to know.

Re: Instant database clones with PostgreSQL 18

#96

Earlier quoted context omitted.

Mostly.. App migrations that may fail and need a rollback have the problem that you may not be allowed to wipe any transactions so you may want to be putting data to a parallel world that didn't migrate.

> App migrations that may fail and need a rollback have the problem that you may not be allowed to wipe any transactions so you may want to be putting data to a parallel world that didn't migrate. This is why migrations are supposed to be backwards compatible

https://github.com/flyway/flywaydb.org/blob/gh-pages/documen...

You can certainly bet you followed that advice correctly, now what are the odds you could test a what-if like that in sufficient depth?

Re: Instant database clones with PostgreSQL 18

#97
I set this up for my employer many years ago when they migrated to RDS. We kept bumping into issues on production migrations that would wreck things. I decided to do something about it.

The steps were basically:

1. Clone the AWS RDS db - or spin up a new instance from a fresh backup.

2. Get the arn and from that the cname or public IP.

3. Plug that into the DB connection in your app

4. Run the migration on pseudo prod.

This helped up catch many bugs that were specific to production db or data quirks and would never haven been caught locally or even in CI.

Then I created a simple ruby script to automate the above and threw it into our integrity checks before any deployment. Last I heard they were still using that script I wrote in 2016!

Re: Instant database clones with PostgreSQL 18

#98
post #55

Earlier quoted context omitted.

There was a recent wave of such comment on the rust subreddit - exactly in this shape "Oh you mean you built this with AI". This is highly toxic, lead to no discussion, and is literally drove by some dark thought from the commentator. I really hope HN will not jump on this bandwagon and will focus instead on creating cool stuff. Everybody in the industry is vibecoding right now - the things that stick are due to suff…

> Everybody in the industry is vibecoding right now no ‘everybody’ is not. a lot of us are using zero LLMs and continuing to build (quality) software just fine

Justifiably, there is 0 correlation between something written manually and quality - in fact I argue it's quiet the opposite since you were unable to process as much play and architecture to try & break, you have spent less time experimenting, and more time pushing your ego.

Re: Instant database clones with PostgreSQL 18

#100

Earlier quoted context omitted.

I have not done this so it’s theorycrafting but can’t you do the following? 1. Have a local data dir with initial state 2. Create an overlayfs with a temporary directory 3. Launch your job in your docker container with the overlayfs bind mount as your data directory 4. That’s it. Writes go to the overlay and the base directory is untouched

But how does the reset happen fast, the problem isn't with preventing permanent writes or w/e, it's with actually resetting for the next test. Also using overlayfs will immediately be slower at runtime than tmpfs which we're already doing.

Resetting is free if you discard the overlayfs writes, no? I am not sure if one can discard at runtime, or if the next test should be run in a new container. But that should still be fast.

If your db is small enough to fit in tmpfs, than sure, that is hard to beat. But then xfs and zfs are overkill too.

EDIT: I see you mentioning that starting the db is slow due to wiping and filling at runtime. But the idea of a snapshot is that you don't have to do that, unless I misunderstand you.

Post reply on HN