3 ms·
I'm probably a bit naive about this but could it make it unnecessary to explicitly create database dumps as backups in scenarios where you need a rollback? ie:
by zmmmmm 6y ago
I'm probably a bit naive about this but could it make it unnecessary to explicitly create database dumps as backups in scenarios where you need a rollback? ie: could I just tag the database and be guaranteed I would later get back that data if, for example, my upgrade failed and I wanted to restore, simply by checking out the tag?
- mildbyte 6y agoThat does sound very ambitious for now! I discussed below that we're focused on the OLAP use case (manage actual data, not DDL around it), so triggers, indexes and functions that you create won't be stored in the Splitgraph image you'll make (a Splitgraph image is not a full database dump). For things like schema migrations, PostgreSQL itself has transactional DDL: column deletions/additions can be wrapped in a transaction, so you can ROLLBACK if your migration fails. This might be more appropriate for your use case? (Note that you can still add DDL commands to a Splitgraph table after you check it out, since at that point it's just a Postgres table. In theory it would be possible to track DDL changes with some other mechanism, and apply them after loading a version of data)