I read this author's works pretty frequently, but I noticed from her blog (and some others) that it seems like authors have a super high incidence of burnout.

Any other writers want to pitch in on that? I'd think you would feel massive relief when you launch a book

Perhaps. However, I'm in AZ, and the 'tailored search results' are usually the midwest or silicon valley.

I think it depends entirely on what your ISP is handing over for location data. Mine clearly doesn't hand over anything useful.

Exactly. Currently, it doesn't bother me, since the 'your data' and 'your interests' and such for me are so random and sporadic.

Of course, I also don't walk around with everything turned on, checking in at every location, posting reviews about everything. I just conserve my battery life and use GPS only on the rare event I need to do a long distance trip or have to find someplace especially tricky.

Maybe it is different for the English?

I used to enjoy perusing rationalviews.com - but it seems that they're shutting down.

Sorta bummed about that, but I get why. Too few people contributed to the discussions

That's because you have a brain. You wouldn't believe some of the stuff I've seen people try to use.

So much copypasta, often with just enough changed to be hacked into a customer's system.

That's precisely my argument against it.

So - as a long time Oracle DBA (who also loves Postgres), I've been seeing a lot of companies do this sort of move.

There are a couple of downsides, but really - there's a lot more upsides to Postgres than downsides (IMO).

I'd love to hear more detail. We hear a lot from the PostgreSQL team and its fans (amongst whom i count myself!), but a lot less from people on the Oracle side.

Oh, as the benefits of Oracle vs Postgres?

So the biggest in my experience is not enterprise support. Folks generally expect it to be. The biggest is actually flexibility. Oracle DB is good at handling some edge-case scenarios, such as a RAC cluster with a failover cluster running an Advanced Dataguard Reporting instance in a whole different state.

Basically you are running a (super expensive) near real-time cluster that's doing compressed log-shipping to another cluster, and you have a standby on that secondary cluster that's open in a read-only mode. And none of it requires cron jobs or excessively complicated setup.

However... even though I've done stuff like this for a number of clients, there are SO MANY better ways to address these sorts of scenarios with creativity and elbow-grease that Postgres tends to be a better tool.

The caveat, of course, is when the person who sets it up leaves, and some other person has to take over. With Oracle's scenario, it's mostly just a slightly unusual config of a standard set of tools. The more creative Postgres solution might be quite a bit more of a learning curve.

This is just an example off the top of my head, but it is one that came up recently. A client had a shipping/receiving system that could not go down, so the 20k+ per node was trivial. To reduce the load for reporting, they just simply had us open a standby DB for read-only reporting on the failover cluster - and they liked that so much, we set up another one for them local to the offshore reporting team.

It's absolutely possible to do something like that with Postgres clustering, but there's a whole lot fewer folks doing it.

Actually, i was thinking more of the upsides to Postgres - apologies for not being clear.

I thought you were already a huge Postgres advocate? Or do you mean 'upsides to postgres that appeals to heavy oracle sites'? /edit Perhaps that wasn't you...

So #1 benefit of Postgres for Oracle shops is transition cost. It's cheaper than Oracle (by sometimes substantial amounts), and relatively painless to switch to. A lot of code can move unmodified, all the same platforms, and often even the same teams of folks in the same jobs. Postgres scales very well, at the very least it can handle 90% of a given company's Oracle load with no real issue. Things like clustering, backups, failovers, and reporting systems can be re-engineered to work in similar ways on Postgres, though some will require substantial hackery.

The #2 benefit is stability. Oracle has a very bad track record (especially lately) when it comes to patching and supporting older databases. If you just want a DB to sit in the corner and work for a year, with push-button easy security patches at most... Oracle isn't really the product anymore. Oracle CPU (critical patches) are cumulative now, and the bloat is getting out of hand. I recently just installed a set of patches that were almost an extra 5GB for the footprint... minor for a 20TB database, but ridiculous if you're thinking of thousands of small distributed hosts.

What's Oracle's patch deployment strategy now? The last time I had to deal with it was around 2008, when a security update was a tarball with a README file telling you which files to copy where. I've heard it's improved considerably since then.

Not a ton different, if you've used OPatch already. Basically it copies around files, runs a bunch of perl, runs a bunch of sql, and then you run the usual patch upgrade scripts at the end. The in-place patching is safer and smoother in 12c than it was in 11g, but the cumulative patching has really gotten out of hand.

For example - on a QA system we were running a couple of custom one-off patches delivered by Oracle Support. These blew up the entire patch process. I had to stop, back them out, re-patch, then re-apply the one-off patches.

Oh, and 12c is a seriously whiny bitch about XDB. Just for added fun.