An early startup that cannot afford to lose an hour of production data is probably too fragile to survive anyway.
It's an early startup - there's going to be larger interruptions than that to the service and any customers who flee after a one hour loss of production data just didn't value the product enough anyway.
(In the specific startup I was thinking of, I already had some nice automated frequent DB-online dumps to S3 with retention enforced, but I didn't think that was good enough for this particular scenario. But not being sure we coudl recover with PITR/journaling would adding a new single point of failure gamble on the success of a business that otherwise might have a 9+ figure exit in a few/several years, just to save a few hundred.)
Also, I suppose that some of the early startups that have less demanding needs, but are cavalier about their obligations towards customers'/users' data, are still being negligent wrt minimum basic practices.
Maybe one intuitive way to appreciate: Imagine a biz news story on HN, on some startup operations dropping of the ball, with startup founders' names attached, and the story says "...and it turns out they didn't have good backups...". Then one of the cofounders, who's maybe not slept much as their company is crashing around them, responds "Customer data isn't that important in an early startup; if it were, we'd be too fragile" (typed before the cofounder could throw that person's laptop across the room to stop them typing). It wouldn't be a good look.
I'll address this at the end.
> Imagine a biz news story on HN, on some startup operations dropping of the ball, with startup founders' names attached, and the story says "...and it turns out they didn't have good backups...".
ITYM "...and it turns out they didn't have the last hour backed up..."
I can imagine everything in your scenario, even the unsnipped bits, and it all seems normal, unless you read "Our startup clients, who've been using us for a month, all left immediately when we lost the last hour of their data".
I really can't imagine that scenario.
Now, granted, there are some businesses where the benefit to using it is that there is not even an hour of lost data.
IOW, customers use it because it won't lose any data: online document collaboration[1], for example[2]. If you have a meltdown that loses an hour of the last inputted data, then sure, expect all affected current users to flee immediately.
[1] Although, personally, I'd mitigate the risk by duplicating the current document in localstorage while it is being edited.
[2] Maybe stock exchange also needs the system to keep the last hour of data? What else?
Otherwise, I'd have to hire/contract someone very experienced, or dedicate a solid month or more of my time (which was not available), just to be 100% sure we could always restore journaled PITR backups quickly.
I can save orders of magnitude on cloud costs other places, but credible managed PostgreSQL was a pretty easy call (even if the entry-level price tag was more than you'd expect).