PostgreSQL 10 Release Candidate 1 Arrives

[stalkerg]

I want to backport CMake build for stable Postgres10 https://github.com/stalkerg/postgres_cmake . Currently, it is working for 11dev version.

[bug77]

When PostgreSQL will be an Oracle RDBMS by all means? I heard some companies are switching, but not sure about the current status.

You mean you want full JVM running inside PostgreSQL? Because for most of the other stuff, I think you can safely switch today.

[tureba]

When PostgreSQL will be an Oracle RDBMS by all means? I heard some companies are switching, but not sure about the current status.

I was hoping this was rhetorical, but since I fear it was not, here goes.

Think of it from another angle: what killer feature does your current RDBMS have that Postgres doesn't and which impedes the migration of your solution?

You'll realize, like most people do, that you can't come up with a strong answer. The truth is that most apps, even the larger ones, are simple CRUD plus stored procedures with some domain logic. Nothing fancy there. So the difficulty lies in rewriting all that logic either in pl/pgsql (or any other of the dozens of languages that Postgres supports for server-side logic) or, better yet, moving that logic outside of the database to a less noble/pricy location such as up to a level, into the application server. Which means the big cost is rewriting and testing the whole solution from head to toes, which can take months of man-power. There are open sourced tools that automate much of that. Plus, some of the Postgres companies that offer migration services have really impressive tools for both schema, logic and data (I've seen fully automated migrations with just a few clicks plus manually changing the JDBC connection string afterwards).

Sure there are exceptions. For auditing in Postgres you need to write more commands, for partitioning you need to write even more (but v10 is easing this a lot) and so on. And even if you find that one feature that's truly missing, all Postgres companies (https://www.postgresql.org/support/p...ional_support/) provide alternate implementations and solutions of their own. The fact that a feature is not in core doesn't mean you can't find a good way to do it. Citus has sharded db, EDB has impressive tools and most packages reimplemented and so on, each with their specialties, but all handle the simple CRUD/SP case beautifully. And they're all against vendor lock-in, so they'll gladly take migration projects to- and from- Postgres, unlike proprietary vendors.

So that's the main reason: the road to migration is rocky and potentially expensive, but there are no major hurdles in the way. Companies are increasingly realizing that it's cheaper to migrate than to renew $vendor's licenses and that's why we hear of more and more abandoning ship off of proprietary solutions.


EDIT: I keep getting 403 if I try to post longer texts. So the second part of the answer comes after.

[tureba]

When PostgreSQL will be an Oracle RDBMS by all means? I heard some companies are switching, but not sure about the current status.

That should be the end of the proper answer, but I fear that if I don't speak of an extra point, I'll be queried later, so here goes again.

Performance is a common worry that comes up regularly as a question such as "does Postgres have RAC?" or "does Postgres do multi-master?" or some such.

Firstly, some context: RAC is an Oracle solution of single-master (yeah, you heard me), multi-write, shared-everything cluster that's used when a single machine can't handle all the load of the whole database. The cluster starts, elects a master, the master maps all blocks to nodes so that each node controls reads, writes and cache for a certain disjoint set of blocks. If a node needs another's block, it asks for it through the interconnect network instead of going straight to the block. It's designed for monolithic solutions that put all plus the kitchen sink in the database, along with the application logic (usually in pl/sql or jars). Basically, applications that were the state of the art in the 90's. Many would even compose UI descriptions in stored procedures in the database - think of building dynamic html pages inside the database, inside a transaction, while holding locks on several rows; something like that, but xml came out instead and was sent to the java UI later. Not only that, but many times the database is shared by more than one application in order to reduce licensing costs on instances and cores. So that's the context in which people say "but I need multi-master like in RAC".

Fast-forward to today and consider a good architecture by today's standards. Applications go to different instances and independent hardwares. Each application is split into microservices. Shard data that doesn't need to be close to each other (https://www.citusdata.com/blog/2017/08/28/five-data-models-for-sharding/ for a few ideas). Keep transactions as short and as to the point as possible (in fact, you'll realize many times you don't even need them for simple CRUD and that is why nosql solutions have gained ground recently). And most of all, logic goes in the application server or in the client (except for what affects consistency, integrity and indexing, of course). With that in mind, there is absolutely nothing you "need the performance of $proprietary_vendor" for. Of course, taking any step towards a more current architecture costs even more, so when managers realize that the migration may involve more costly architectural changes, they may shy away.

Then there's the contract. Oracle's contract says no one can publish performance numbers - ever. Whenever somebody tries, they get to meet the hardest-working oraclers: the lawyers. And that's the biggest reason why we don't see honest benchmarks around. So we're kept in the dark and fed untestable statements that "Postgres is way behind and never ever catching up with Oracle". That's complete FUD, but works for them nonetheless. It's almost always said by people who haven't used Postgres all that much (though they may be genuine Oracle experts) and propagated by everyone who thinks that someone down the line made trustworthy and honest benchmarks somewhere beyond the horizon - the very definition of an urban legend. But if you meet with people experienced on both worlds behind closed doors, they'll show numbers on single machine that indicate the TPS is very much on par on many cases, higher or lower in others; but definitely not behind. And others will show an impressive TPS on master-slave when using hot standby (writes are usually fewer and they go in the master; reads go on the however many slaves you need, so you get an impressive scaling). Some will even show you real multi-master solutions for horizontal write-scaling. So you just have to dig deeper and not give into the FUD.

So the conclusion of this second part is: if you think you need multi-master, you probably don't; if you're worried about the performance, either do the tests yourself or get someone reliable to do them in front of you. But for all that is sacred, don't blindly give into the negative marketing.