Binary JSON Support Added To PostgreSQL, Competes With MongoDB

[phoronix]

Phoronix: Binary JSON Support Added To PostgreSQL, Competes With MongoDB

In a sign of PostgreSQL trying to better compete against MongoDB with its "BSON" (binary JSON), PostgreSQL now has support for a binary JSON data type...

http://www.phoronix.com/vr.php?view=MTY0MTU

[sarmad]

Great news, no need to learn MongoDB now.

[peppepz]

Does this mean that postgresql is web scale now?

[grigi]

postgresql was at "big data scale" already, which is quite a bit more than "web scale" :-P
Mongo isn't bad, I use it for quite a few things, it just is nearly impossible to maintain in the classical "enterprise" sense, PostgreSQL has some pretty awesome on-line backup functionality.

I'm excited about all the cool stuff going into PostgreSQL :-) I have been a fan since I realised it is just about the only DB that doesn't silently destroy your data :-)
(mysql is pretty bad at this, so is Sybase and MSSQL, didn't have enough experience with Oracle to determine if it also silently mangles your data)

[Pajn]

This could be great. Will have too see and wait how it turns out.

[Lennie]

scale

postgresql was at "big data scale" already, which is quite a bit more than "web scale" :-P
Mongo isn't bad, I use it for quite a few things, it just is nearly impossible to maintain in the classical "enterprise" sense, PostgreSQL has some pretty awesome on-line backup functionality.

PostgreSQL can scale very large in the "vertical" fashion (very large machines), but it's still limited in how it can scale in the 'horizontal' fasion. Basically it still is 'just SQL', not NoSQL. A lot of NoSQL solutions can be easier to scale, but give you less guarantees about your data. Basically, most do some kind of sharding.

With PostgreSQL you can also easily create many readonly slaves with replication, for handling many readonly queries. But that doesn't help scaling write queries.

And it has lots of other tricks like plugins/extensions to talk to memcached or redis to for example update a fast in memory cache.

There is also Postgres-XC which can scale much larger but isn't part of normal PostgreSQL which means it is always a release or 2 behind and does not support and maybe never be able to support all the normal PostgreSQL features.

You might have noticed that the article also points to the Logical Decoding patch that will also be part of PostgreSQL 9.4. Which is the first part of a whole bunch of possible larger projects which some will hopefully go into 9.5.

The original developer of the Logical Decoding is working on Bi-Directional Replication. Which is intended to create multi-master-like replication solutions. Which seems like it might perform better than the other existing solutions. Maybe it will also help get parts of Postgres-XC or similar solutions in the core PostgreSQL project. Or maybe even make the code base of Postgres-XC smaller so it is closer to the normal PostgreSQL version.

There are also people that think Logical Replication might be something they want to work on because that allows Selective Replication which would give you replication of just a database or table or other criteria like projects like Slony-I do now, but with better integration and performance. Slony-I also allows to replication between versions, this is something people also want to use Logical Replication for. Because that allows you to do easier upgrades in large installations.

9.4 also has some core changes which will help with getting PostgreSQL to support Upsert. Which means Upsert might get into 9.5. In certain cases Upsert can also perform a lot better than the workarounds.

So there are lots of changes in 9.4 and lots of potential changes which could help scale PostgreSQL even further than it does now.

[uid313]

Vanity license

It is too bad Postgres has a vanity license, because it seems like a really great database.

I believe the vanity license is holding it back.

[Lennie]

It is too bad Postgres has a vanity license, because it seems like a really great database.

I believe the vanity license is holding it back.

Maybe, it's hard to say if that is true.

Clearly the MySQL model worked even less well.

And companies like RedHat, VMWare, EnterpriseDB, PostgreSQL Experts, Command Prompt, Disqus, 2ndQuadrant, Heroku, Skype, NTT, Google, Salesforce, Mozilla and in the case of this JSON support Engine Yard seem to have no problem contributing to PostgreSQL.

[uid313]

Maybe, it's hard to say if that is true.

Clearly the MySQL model worked even less well.

And companies like RedHat, VMWare, EnterpriseDB, PostgreSQL Experts, Command Prompt, Disqus, 2ndQuadrant, Heroku, Skype, NTT, Google, Salesforce, Mozilla and in the case of this JSON support Engine Yard seem to have no problem contributing to PostgreSQL.

It is harder to get it packaged into distributions.

Also it is harder to get permission to use it in companies, because lawyers are not familiar with the license since its not a common open source license, so it takes extra time and money to get the license through the legal department.

http://www.groklaw.net/articlebasic.php?story=20050718165335943

[Lennie]

It is harder to get it packaged into distributions.

Also it is harder to get permission to use it in companies, because lawyers are not familiar with the license since its not a common open source license, so it takes extra time and money to get the license through the legal department.

http://www.groklaw.net/articlebasic....50718165335943

Maybe I'm confused, English isn't my first language, but isn't PostgreSQL using a license very similar to MIT or BSD ?

Is it really that vanity ?

I would have prefered if it said, something along the lines of what is in the OpenLDAP license:

"OPENLDAP FOUNDATION AND ITS CONTRIBUTORS "

Instead of:

"UNIVERSITY OF CALIFORNIA"

http://www.postgresql.org/about/licence/