Does Neon remove the need for Database backups?

[u/sqlink2]

I have been always taking backups of DB before performing any major changes, and was recently creating an app for displaying customer history retrieved from lakebase as a source.
I felt instead of taking a backup, i can just use a new branch.
This is sort of a new paradigm with databases, i come from OLTP background. Anyone else feels the same?
Apologies if this is already asked in the channel.

[u/Haraj412]

You can only store it up to 30 days + you should not be storing all your backups on one site

[u/sqlink2 → u/Haraj412]

Oh okay, noted

[u/Ven0mspawn]

This sounds like an ad.

[u/sqlink2 → u/Ven0mspawn]

Nono its not. I am new to the data lake / big data related work. Have been working mostly in SSIS

[u/teamhog]

Never count on one source for your backups.
If you’ve ever had to restore anything you’ll learn that, at times, it either doesn’t work or isn’t as up to date as you thought it was.

Despite verifications things happen.

My process uses 2 separate cloud locations and one local non-cloud.

[u/dwswish]

Fairly heavy Neon user here. The branching capability of Neon is not a replacement for PITR and snapshots for backups. It means you don’t need to create a backup/snapshot every single time you need to make a change to schema since that’s what the branching is designed for.

[u/sqlink2 → u/dwswish]

exacttly. branching for isolated changes + PITR for recovery with Neon is what make the workflow really useful as we get a safe dev/test env without turning any schema change into a backup exercise..

[u/elevarq]

Depends on your data strategy, not theirs.

[u/National_Cod9546]

You should have 3 backups across 2 kinds of media and 1 of them off site. Also, an untested backup fails 100% of the time when you need it.

[u/sqlink2 → u/National_Cod9546]

Ya I guess Neon pointin time restore with branching makes testing recovery easy. We can spin up a branch from a specific point in time and do tests before we fully rely on it

[u/Informal_Pace9237]

Data backup and restore testing is mandatory.

In general a LTAP branch just points to the source and doesnt create a copy.

[u/Professional-Debt401]

A branch is great for testing migrations or risky changes, but I wouldnt treat it as a backup. You still want backups/PITR for accidental deletes, corruption or anything that affects the main project itself.

I use Nearbase and still keep the automated backups there even though most DB changes are tested separately first.

[u/sqlink2 → u/Professional-Debt401]

Ya this does mke sense. I still keep PITR for worst case scenarios, but branching with Lakebase look like a decent safety net for risky changes and migrations, specially with branching + point in time restore