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

OP here - yes, this is my use case too: integration and regression testing, as well as providing learning environments. It makes working with larger datasets a breeze.

If possible could you share a repo/gist with a working docker example? I’m curious how the instant clone world work there.

Actually, a "ghost station" shell has existed under Satellite 3 since 1998, though it was never finished or opened to passengers. The tunnel was built that far just to give the trains space to turn around.

I wouldn't usually use the 'non-native speaker argument', but thank you! Just yesterday I was accused of sounding like AI - https://news.ycombinator.com/item?id=46262777 - my default mode is that I oscillate between sounding too boring/technical, or when trying to do my best, sounding like AI

Your article is obviously written by Slavic writer, haha. Characteristic sound of Slavic tint to the prose. If it is LLM, then prompt engineering is good. I believe it is mostly human-written.

Yes, I'm Czech.

OP here - thank you for mentioning replica, forgot to mention it. Unless it would hit it pretty hard and `hot_standby_feedback` is on

Author here – it’s actually funny, as you pointed out parts that are my own (TM) attempts to make it a bit lighthearted.

LLM is indeed used for correction and improving some sentences, but the rest is my honest attempt at making writing approachable. If you’re willing to invest the time, you can see my fight with technical writing over time if you go through my blog.

(Writing this in the middle of a car wash on my iPhone keyboard ;-)

Yeah, I get accused of being an LLM all the time as well, best to ignore that kind of slop... (which, ironically, goes both ways!)

Author here - thank you for the comments. This article is indeed playing a lot on verge of clickbait and I did asked about that shortly after publishing.

No worries -- not publishing at all is worse than publishing disliked content (well, to a certain extent), so keep reading that feedback, but don't be too discouraged by it!

It’s very unpleasant to read. I did find the article useful nonetheless.

Let me be clear - this is just baseline testing that's only valid for similar data patterns, same cardinality, and so on. Plus it's currently using EXPLAIN, so we're working with estimates, not actual execution data.

But from my experience, this is low-hanging fruit for catching regressions that could break your application without you noticing. The performance work you're describing is the real nitty-gritty database management - the deep optimization work that truly makes or breaks an app.

For that there's no silver bullet.

For regression testing I struggle to see how a new SQL only test runner improves over a project’s existing testing systems. I think any project using a database should have integration tests that combine testing application logic with their database access queries. Your system does some explain checking but to me it feels tenuous if it’s worth the complexity required to dump all the queries my app may perform to text / YAML and adding yet another test runner in CI.

I think one interesting angle would be to integrate your assertions directly into Postgres as a plugin. That way, you can spy on every query issued in any test framework, dump the text automatically, and prove additional assertions about the query plan index use perf etc, regardless of the user’s primary language. That would also get you out of needing to build 1000 different integrations for all the programming language / ORM combos in the universe. If you don’t want to do a Postgres plugin you could also do this as a Postgres wire protocol proxy.

Hey, thank you for follow-up. Really appreciated. This is why I decided to go out and show RegreSQL.

You're absolutely right that in an ideal world, every project would have solid integration tests covering their database access queries. That's the goal everyone should aim for. Unfortunately there again and again cases where developers are afraid of SQL and databases and it's not uncommon to see very simple things sending applications to crawl.

As for the second point, that's a direction I would love to get. Whatever it can be directly, as part of open source or service is something to be decided - but tracking the trend data there would provide a lot of value indeed.

For now the syntax is not fully compatible - but my goal is to add https://github.com/boringSQL/queries (library behind SQL files parsing) to better align on it. It's definitely on my radar

I'm obviously biased. Adding MySQL support is not that difficult but maintenance is (and ultimately PostgreSQL is better way forward (half joking :))

With current feature set it's something I have already considered but still undecided.

Are there interfaces that we can use to implement support for other databases?