Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What if database branching was easy?

xata.io

Post reply on HN
Print view View original

11–20 of 59 posts

Re: What if database branching was easy?

#11

Post by eatonphil »

sastraxi wrote: post #5

I’ve done experiments using BTRFS and ZFS for local Postgres copy-on-write. You don’t need anything but vanilla pg and a supported file system to do it anymore; just clone the database using a template and a newish version of Postgres. Looking at Xata’s technical deep dive, the site claims that we need an additional Postgres instance per replica and proposes a network file system to work around that. But I don’t real…

I also don't really understand how being correct under physical branching with ZFS, or physical backups of a filesystem, are different from crash safety in general. As long as you replay the WAL at the point where you branch (or take a physical backup of the filesystem) you should not lose data?

At the same time Postgres people don't seem comfortable with the idea in practice so I'm not sure if this is actually ok to do.

Re: What if database branching was easy?

#12

Post by sgarland »

> Imagine you need to add an index to a table with a few million rows. On a seeded database with 200 rows, the migration runs in milliseconds. Obviously. But on a branch with realistic data, it takes 40 seconds and needs CREATE INDEX CONCURRENTLY to avoid locking the table. The branch is isolated, so locking there isn't the issue — the point is that the rehearsal shows the production migration would need CONCURRENTLY.

A few million rows should take at most, on the most awful networked storage available, maybe 10 seconds. I just built an index locally on 10,000,000 rows in 4 seconds. Moreover, though, there are vanishingly few cases where you wouldn't want to use CONCURRENTLY in prod - you shouldn't need to run a test to tell you that.

IMO branching can be a cool feature, but the use I keep seeing touted (indexes) doesn't seem like a good one for it. You should have a pretty good idea how an index is going to behave before you build it, just from understanding the RDBMS. There are also tools like hypopg [0], which are also available on cloud providers.

A better example would be showing testing a large schema change, like normalizing a JSON blob into proper columns or something, where you need to validate performance before committing to it.

0: https://github.com/HypoPG/hypopg

Re: What if database branching was easy?

#13

Post by hilariously »

eatonphil wrote: post #11
sastraxi wrote: post #5

I’ve done experiments using BTRFS and ZFS for local Postgres copy-on-write. You don’t need anything but vanilla pg and a supported file system to do it anymore; just clone the database using a template and a newish version of Postgres. Looking at Xata’s technical deep dive, the site claims that we need an additional Postgres instance per replica and proposes a network file system to work around that. But I don’t real…

I also don't really understand how being correct under physical branching with ZFS, or physical backups of a filesystem, are different from crash safety in general. As long as you replay the WAL at the point where you branch (or take a physical backup of the filesystem) you should not lose data? At the same time Postgres people don't seem comfortable with the idea in practice so I'm not sure if this is actually ok to…

Crash safety does mean rollbacking all things in progress, but yes, if your database cannot safely do it (even if it is yucky) then you do not have a safe database for any crash situation.

Re: What if database branching was easy?

#14

Post by hilariously »

comrade1234 wrote: post #2

I was on a big team working on a giant oracle database over 25-years ago. I dont remember the term but each developer had their own playground of the giant database that wasn't affected by anyone else. The DB admin would set it up for each developer in just a few minutes so it definitely wasn't a copy. Then when a developer needed to reset and go back to the original db again it just took a few minutes. I just don't…

Sounds like a snapshot - a file based diff of the pages changed since the last full backup - easy to revert to for the same reasons.

Re: What if database branching was easy?

#16

Post by nathell »

xeubie wrote: post #9
Nihilartikel wrote: post #3

This kind of magic is the reason that I'm very itchy to be able to line up real work on Datomic or XTDB someday.

Surprisingly, neither Datomic nor XTDB support branching. See: https://blog.danieljanus.pl/datomic-forking-the-past/ I actually built my own immutable database which does support branching (see profile), so it seems like a huge miss that these ones don't. It's pretty much the main reason I would want an immutable database.

It appears that Datahike [0] is a Datomic workalike that supports branching. I haven’t tried it out myself (yet), but the documentation suggests it’s possible [1].

That said, I’m adding xitdb to the list of tech to try out. Thank you for building it!

Oh, and thanks for linking to my article :-)

[0]: https://github.com/replikativ/datahike

[1]: https://datahike.io/notes/the-git-model-for-databases/

Re: What if database branching was easy?

#19

Post by camdez »

xeubie wrote: post #9
Nihilartikel wrote: post #3

This kind of magic is the reason that I'm very itchy to be able to line up real work on Datomic or XTDB someday.

Surprisingly, neither Datomic nor XTDB support branching. See: https://blog.danieljanus.pl/datomic-forking-the-past/ I actually built my own immutable database which does support branching (see profile), so it seems like a huge miss that these ones don't. It's pretty much the main reason I would want an immutable database.

Wait, this statement seems way too strong.

The linked article points out that Datomic doesn't support branching from the past. It absolutely does support branching, and I've built entire test suites that way.

From a cursory glance, I'd say Datomic does exactly what the original parent article is discussing. It works great and it's super convenient.

Post reply on HN