New PostgreSQL Guns For NoSQL Market 162
angry tapir (1463043) writes "Embracing the widely used JSON data-exchange format, the new version of the PostgreSQL open-source database takes aim at the growing NoSQL market of nonrelational data stores, notably the popular MongoDB. The first beta version of PostgreSQL 9.4, released Thursday, includes a number of new features that address the rapidly growing market for Web applications, many of which require fast storage and retrieval of large amounts of user data."
next for NoSQL (Score:5, Insightful)
Re: (Score:3)
Impossible.
The entire premise behind NoSQL is trading consistency for availability (which actually means "latency" since everything is eventually available). You will never ever get ACID from NoSQL databases.
Re:next for NoSQL (Score:4, Informative)
Re:next for NoSQL (Score:5, Interesting)
All "NoSQL" means is that the database doesn't use SQL as its interface, nor the massive infrastructure needed to implement the SQL standard. This lets you build some things that lighter than SQL-based things, like schemaless data stores. There several consistency models that let you have a fair comparison. It's not the case that NoSQL must trade consistency for availability in a way that makes it impossible to move toward SQL spec behavior.
Differences include:
Key-value indexes are small and efficient to navigate,
Today NoSQL solutions like MongoDB still have a better story for sharding data across multiple servers. NoSQL also give you Flexible schemaless design, scaling by adding nodes, and simpler/lighter query and indexes.
PostgreSQL is still working on a built-in answer for multi-node sharding. A lot of the small NoSQL features have been incorporated, with JSON and the hstore key-value index being how Postgres does that part. Both system have converged so much, either one is good enough for many different types of applications.
Re: (Score:2)
the SQL standard.
That's cute
Re:next for NoSQL (Score:5, Insightful)
http://en.wikipedia.org/wiki/S... [wikipedia.org]
"Popular implementations of SQL commonly omit support for basic features of Standard SQL, such as the DATE or TIME data types. The most obvious such examples, and incidentally the most popular commercial and proprietary SQL DBMSs, are Oracle (whose DATE behaves as DATETIME,[30][31] and lacks a TIME type)[32] and MS SQL Server (before the 2008 version). As a result, SQL code can rarely be ported between database systems without modifications."
That's why its cute.
Re: (Score:2)
Yeah, it's irritating, but should not be an insurmountable obstacle for migrating schema+data. I have done this thrice for a database consisting of 40 tables and about 2.7 million rows total (DB2 -> PostgreSQL 7.something, DB2 -> SQL Server 2005, and SQL-Server -> PostgreSQL 9.1). Yes, I know that those numbers are small-ish, but the data contained a lot of user input and included every quirk and special character under the sun :)
This database was storage for a Java application using Hibernate, whi
Re: (Score:2, Interesting)
"Schemaless design" always just sounds like a whitewashed buzzword for "Excel spreadsheet" to me.
There's a very simple way to make a "schemaless design" within a relational database, and it's generally regarded as Not Best Practice (tm). You need a table with a unique PK (any old GUID or autoincrementing integer will do just fine), a FK to whatever bit of "real indexing" you need (user id or whatever), and two string fields (varchar, nvarchar, character varying, whatever your RDBMS likes to call them). One
Re: (Score:2)
Nobody that feels a need to use NoSQL is going to consider using PostgreSQL for that task
Unless they're already using Postgres for something else, and the server is already running, and they'd like to be able to use all the same tools and scripts to manage their NoSQL databases as their PostgreSQL databases. In which case, this could be a big help.
Why so negative? Just a hobby?
Re: (Score:2)
While your parent *was* a bit snarky in his reply, I can see only two reasons why you would try to finagle your NoSQL needs into a PostgreSQL server: you don't understand how to use a traditional RDBMS but would still like to advertise that you're using PostgreSQL instead of MongoDB (not likely for most devs), or the decision is made for you by management for the reasons you mention. If you need some NoSQL solution in a new project it's not very difficult to create an instance, and the infrastructure for th
Re: (Score:1)
Not really (Score:2)
"NoSQL" is a pretty bad name actually. They should be called non-relational databases. In many cases you can use SQL or something like SQL on them.
People never use NoSQL to get away from the SQL language (although I don't like SQL at all). They use it to change the trade-offs in ACID complacence and to not have to keep their data completely relational.
Re: (Score:2)
A typical file system is a non-relational database. Does that make it NoSQL?
Re: (Score:1)
Martin Fowler discusses the NoSQL moniker and seems to agree with you: https://www.youtube.com/watch?... [youtube.com] It' NoSQL Distilled to an hour by Martin Fowler from NoSQL Matters Conference
Re: (Score:1)
Impossible.
The entire premise behind NoSQL is trading consistency for availability (which actually means "latency" since everything is eventually available). You will never ever get ACID from NoSQL databases.
There are already NoSQL databases supporting ACID: http://ravendb.net/ [ravendb.net]
Re: (Score:2)
Except that indexes are only BASE. Good luck with querying it ....
Re: (Score:2)
Except that the transactions in MongoDB can touch only a single document. Which kinda makes the whole ACID idea pointless, because that's about consistency of the whole database. Saying "it's ACID, but only within a single document" is a bit like "you can have any color, as long as it's black".
I'm not sure about CouchDB - I know it used the same approach (single-document transactions), but maybe that changed a bit.
One of the absolutely terrible things coming from the whole NoSQL movement is redefinition of
Re: (Score:1)
Neither of those terms have been redefined. Hell one of the key features of most NoSQL databases is "Eventually consistent" and I have no idea what you think you mean by "availability": I've had far, far, better experiences clustering MongoDB and Redis than I ever have with (eurgh) MySQL
Re: (Score:1)
MyISAM was considered ACID
Hahahahahahahahahaha.
Re: (Score:2)
Re: (Score:1)
I prefer to use Mongo when prototyping - when the data structures are still in flux, and I want something quick, flexible, and - most importantly - right now.
That, and setting up MongoDB is a breeze: `aptitude install mongodb`, and you can start using it straight away.
Comment removed (Score:4, Interesting)
Re:How about Parallel Query Execution? (Score:5, Interesting)
Look at Postgres-XL [postgres-xl.org] that we just released. It's a clustered database and can do MPP execution of your queries and has good write-scalability too. (To use all the processors in each machine, you'll want to have a few data nodes per machine.) It's pretty clever about planning a lot of things.
Re: (Score:2)
Re: (Score:3)
Really premature, and unlikely in any event.
I think Postgres is good for what it is-- a clean, single-node database system. Clustering adds some complexity in deployment (we're working on making this easier) that you wouldn't want to incur for a typical Postgres install.
I think there are pieces of Postgres-XL that make sense to be in core/vanilla PostgreSQL, and we'll be working to contribute them upstream. Likewise, there are more pieces from TransLattice's commercial database offering, TED, that Postgre
Re: (Score:2)
I like the way the linked page uses Web 2.0 when it means scalability.
Great job with the buzzwords.
Re: (Score:3)
I like the way the linked page uses Web 2.0 when it means scalability.
Great job with the buzzwords.
You know, I was just going to let this go, chalked up as random Internet stranger being an asshat, but seriously. Are you SO bored or jealous of other people's achievements that you have nothing better to do than to sit around and nitpick the friggin' ad copy of a marketing page that was undoubtedly written not just for people who want to know the technical specifications of the product, but common usage applications for it also? What you're calling a "buzzword" is information that business wonks need to
Re: (Score:2)
So what exactly does 'web 2.0' mean? Because I can tell you it's a completely vague term, used to create hype around so many disparate concepts it lost all the meaning it once had. And even if you manage come up with some definition, do you really think the business wonks will understand it / should be responsible for choosing the technology?
Wootery implied nothing about Postgres being incapable database system, just that the 'web 2.0' is a buzzword. That says nothing about Postgres (or rather Postgres-XL,
Re: (Score:2)
Are you SO bored or jealous of other people's achievements that you have nothing better to do than to sit around and nitpick the friggin' ad copy of a marketing page that was undoubtedly written not just for people who want to know the technical specifications of the product, but common usage applications for it also?
I'm a techie. Like many, I find vacuous marketing to be grating. That's really all I was trying to get across. It's a very minor detail, and a very minor dig. I'm not attacking your product.
(I can play at quasi-psychoanalysis though, if that's the game: are you so insecure about your product you have to rant at snarky Slashdotters, and imagine further insult which isn't there?)
What you're calling a "buzzword" is information that business wonks need to know when faced with the question, "Will this solve my problem/fulfill my needs?"
Other than a mention of JSON support, nowhere on the page are there any web-specific points being made. The section labelled 'Web 2.
Re: (Score:2)
Sure, and it inherits from Postgres-XC significant code.
However, it has a few things Postgres-XC doesn't. First, if you write a complicated join, Postgres-XC sends the entire tables involved in the join back to the coordinator node, which then promptly dies/grinds to a halt. Postgres-XL has a planner that is able to A) push down much more of complicated queries, and B) allow tuples involved in sophisticated queries to flow directly between the different data nodes.
Postgres-XL's planner is also able to run
Re: (Score:2)
You can try it in the cloud for free for small datasets/poke around by signing up at http://stormdb.com/ [stormdb.com] .
The database server itself is a little harder to deploy than PostgreSQL, but we have a fairly decent set of documentation (feedback appreciated) at http://files.postgres-xl.org/d... [postgres-xl.org] . As far as application support goes--- if it runs on Postgres, odds are it will run on Postgres-XL.
Re: (Score:1)
Do you really have enough I/O bandwidth in the machine to keep multiple processors busy on a single query?
No SQL (Score:3)
It would be nice if noSQL databases adhered to the promise in the name. They replace the query language with something sane and secure.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
No they aren't. Object databases are not relational they are hierarchical. Associative databases are associative not relational. And many of the "NoSQL" databases the partitioning scheme changes the outcome of queries which is a complete violation of the relational concept that order of rows doesn't effect the return from invoking queries.
Re: (Score:2)
No they aren't. Object databases are not relational they are hierarchical.
The only CORBA implementation with which I've ever been familiar definitely used a relational store, and made relational queries. I think you are speaking a little too generally.
Re: (Score:2)
I haven't played around with Object Database and CORBA. But at least on first glance the two seem to be pulling in opposite directions. An Object Database at its best is an extension of memory for a family of applications all sharing a common object library. Essentially one big application. CORBA is moving in the idea of relational, but even further, trying to separate data from the underlying application. It seems to me that's an either / or choice.
Re: (Score:2)
I'm talking about intermediate calculations. Just to pick a stupid example say you had a 3 row database and one of the columns was a 2*2 matrix. You wanted to take the product.
a*b*c != b*a*c so row order matters but
a*(b*c) = (a*b)*c so order of computation does not.
Re: (Score:1)
So what's wrong with SQL? I've honestly never found myself thinking it sucks as a query language, and the parts I did think sucked outright monkey balls with package-specific functions (Oracle sucks bad for this in places...)
I hear this complaint a lot but it's never really quantified by those who say it and I'd love to know why. If what people meant to say is 'I hate having to organise my data into relational tables and hate having to deal with the process of upkeep and curating my data' then yes, that i
Re: (Score:2)
Right. Implementing this without SQL is so much simpler.
Oh wait ...
Re: (Score:2, Interesting)
The main problem is that SQL sucks.
Compared to what? I'm not sure you have any idea what kinds of inflexible horrors preceded the relational systems. Furrthermore, SQL is based on relational algebra, which underlies the whole RDBMS concept; if you need a data manipulation language closely matching the capabilities of an RDBMS, it has to be set-oriented and based on relational algebra (or relational calculus, which is equivalent). And there you have the root cause of the problem: a serious impedance mismatch between a set-oriented query langu
Horizontal scalability? (Score:3, Interesting)
Re:Horizontal scalability? (Score:5, Informative)
We just released Postgres-XL [postgres-xl.org] so you can have horizontal scalability and MPP.
Re: (Score:2)
Re: (Score:2)
Honestly, just organizational readiness. We are likely to move to a BSD-style license in the future... but initially taking a license that made it a little harder to have a closed-source fork was easier to convince some members of the team/board. (There's been a significant amount of investment in producing this codebase and we wanted to make sure we didn't immediately enable a competitor).
Going in the wrong direction (Score:1)
Most people don't need NoSQL. Last I checked, most people aren't Facebook or Google. And ironically those two companies are lining up behind http://en.wikipedia.org/wiki/N... [wikipedia.org]
ACID is here to stay. We will see conventional databases improve in the latency space and NoSQL will (mostly) go away.
Re:Going in the wrong direction (Score:5, Insightful)
Some people get overly optimistic about their start-ups or new projects. It's like planning on where to park all the beemers before you even get your first sale.
Re: (Score:1)
"NoSQL" is a band-aid while programmer competence catches up with resource constraints. This old cartoon continues to be relevant [youtube.com], but mostly it's, "We don't know how to use this wheel, so we're going to reinvent it poorly. Eventually our duplication of effort will be complex enough that we're going to need to move something indistinguishable from the traditional system, but nobody needs to say that yet."
It's like the programming language rule that everything eventually looks like a reimplementation of LISP
Going in the wrong direction (Score:1)
Going in the wrong direction (Score:1)
Is it web scale? (Score:1, Funny)
Is Postgres now web scale?
Re: (Score:2)
Is Postgres now web scale?
That depends: are you going to blow some project to hell because you get a woody playing with software like it's a sex doll?
the hype (Score:5, Insightful)
As a big fan of SQL database, I've been watching this NoSQL hype for a few years now, and I'm still not impressed.
No doubt, there are a few scenarios where a conventional database isn't the best solution. But quite honestly, 90% of the people jumping on the bandwaggon would be served just as well with an SQL database - except that like so many things, you need to do it right.
I'm no database expert (but I know a couple), so my SQL isn't perfectly optimized and stuff, but even with a little bit of interest I see that putting some effort into your database and query design pays off massively.
And I've seen enough cases where someone scraped their SQL database and went NoSQL for absolutely no good reason. You think you're huge and SQL is too slow? Unless you just sold to FB or Google for a couple billions, you very likely are not as huge as you think. I'm running a PostGIS database doing fairly complex geography calculations on non-trivial datasets, and it's blazing fast, and whenever it isn't one hour with an SQL expert and some experimenting makes it so, because it always, with no exception, turns out that my SQL or my database design is at fault, not the database itself.
If you've got a billion users, I will grant you that you have special needs. But every NoSQL use I have seen has been a case of people moving database work to software code instead, mostly because programmers are plenty and cheap, while experienced database experts are not.
So I'm still amused and very little impressed, and I'm certain NoSQL will go the way of Java or every other hype ever - for a while it's everyone's darling, then people realize it still doesn't give us AI and it can't make coffee, and will start to figure out where it actually is the best solution and stop using it for everything else.
Re: (Score:3)
I've seen this a million times. People with poorly designed relational databases with no thought given to query plans complain that their database is slow. They then migrate said database to a NoSQL solution (typically a document database like MongoDB) and then find that it is still slow! . In a few cases, the NoSQL solution is significantly slower.
The problem is NoSQL encompasses many different types of solutions. Key value stores like Redis are pretty good (key lookups support wildcards!!!) and I use the
Re: (Score:3)
There's a pretty good book I own in paperback (electronic versions available) for high performance stuff from PostgreSQL. It's called PostgreSQL 9.0 High Performance [amazon.com]. It's probably beyond what you want, but if you're interested in looking at it, let me know and I'll bring it next time we get together.
Re: (Score:2)
Re: (Score:2)
I do. Re-read my original posting, and this time until the end. :-)
Re: (Score:2)
I don't have a problem with relational databases, but even though I'm pretty good at writing SQL queries, I don't like SQL as a language.
There should be a middle ground somewhere between SQL, Map-Reduce and Object Oriented coding styles. I want code reuse, I want encapsulation, I want LLVM-like compiler optimisations. I want to push as much processing down to where the data is, without needing to hand optimise everything.
SQL doesn't provide much of those things.
Re: (Score:3)
Because it's a database.
SQL is 40 years old. In that time, dozens of programming languages, patterns and styles have come and gone. And SQL is still here, exactly because it doesn't care if your language is OO, functional, redundant, brainfuck or agile deployment for optimized synergies with next generation engagement framework whatever.
A database needs to concern itself with the data, not with the programming patterns of the application.
Re: (Score:2)
Writing queries on databases with large numbers of heavily normalised tables is a pain. Many queries end up similar or the same, with common table joins, and similar filter criteria. Sometimes this means you end up writing front end code to emit SQL, so that you can increase the flexibility of your application. And then you want to change the structure of a few tables. Good luck hunting down all of the queries in your app that need to change.
Or if a query gets too complicated for the database to use the ri
Re: (Score:2)
Good luck hunting down all of the queries in your app that need to change.
You've heard of database abstraction layers, yes? :-)
Here is how I and everyone sane I know develops: Write straighforward code and queries first. Then check where your performance bottlenecks are and optimize those, ignore the stuff where it doesn't matter if you could improve performance. In one current app, I have some queries that get executed on the order of 200,000 times whenever I make a run, and some that get executed ten times. Do I give a flying fuck if I could optimize the queries that get called
Re: (Score:2)
SQL is still there because it is (almost) pure relational algebra, the math is there to prove its correctness and the math can be used to optimize your queries. You can prove that one query returns the exact same lines as another, so the DB can find and run the faster query instead of your slower one.
Re: (Score:2)
Java hasn't exactly gone away.
Anyway there are fundamental design choices.
Relational requires that table row order is completely unimportant i.e. essentially fully commutative
No SQL requires that computations on table row order is merely associative
Many many mathematical operations are associative that are not commutative. That can be a huge change in how data is manipulated computationally far far faster. You don't have to be Google or Facebook you just have to have enough data and complexity that CPU is
Re: (Score:2)
Java hasn't exactly gone away.
Which is exactly what I'm saying.
Every hype ever has always followed the same pattern. First it is the second coming of christ (or, for hypes prior to 0 AD, the first). Then, it is the solution to all your problems and everyone uses it for everything. You can't get venture capital, employment or a marriage without it. After a while, people realize that for some strange reason, sliced bread is really cool, but it isn't really the best armour and the roof is always leaking and the wheels could really be more
the hype (Score:1)
Re: (Score:3)
If your application is really, really simple and you need truly massive amounts of throughput, then NoSQL is no doubt the way to go.
Somewhere between 1% and 10% of the shops doing NoSQL really fall into that category. Maybe as many again might, with enough growth.
Many years ago, long before NoSQL was a thing, I was the sysadmin of one of the largest e-commerce operations in my country. We had enough users and data and throughput that a big consulting company that was tasked with developing the next-gen syst
Re: (Score:2)
Just like to point out that performance is not the _only_ reason to switch to a noSQL database. For example, in my project we are switching our very small DB to a noSQL solution to have schema-less data. Other examples include: proper Object-Oriented mapping to the database (no hibernate hell,) graph databases, distributed databases with auto-sincronization (part of the database is on a mobile phone and when it connects to the internet it syncs with the remote server automatically.)
Sure you can do all that
Re: (Score:2)
there are plenty of mature and better persistence layers out there than hibernate, that work with SQL database. You lose a lot when you lose schemas, structuring and knowing types of data is very useful for later analysis. Pay now, don't worry about it later
Re: (Score:2)
Some noSQL allows for hybrid schemas (have part of the record be structured and optionally with indexes, but also allow any other data to be added to the record) and that is what I am using. Personally I have not used other persistence layers other than hibernate, but my time with hibernate left me very bitter.
But anyway, that was not the point I was trying to make, the point is that whenever people say "database" they think they need the absolute most efficient thing ever. But there are a myriad of cases w
Re: (Score:2)
People often forget to weight performance against programmer productivity.
That's exactly when you want to use a library, framework, etc.
Personally, I've become a fan of Doctrine 2, which does all the nice object-orientation and other stuff and I still have a SQL database behind it all with its power and performance. Not to mention the crazy stuff you can do with good queries.
Re: (Score:2)
But every NoSQL use I have seen has been a case of people moving database work to software code instead, mostly because programmers are plenty and cheap, while experienced database experts are not.
This, in spades. And my life ( a large part of which is seeing to the performance of our applications) is hell because of it. If I had a dollar...
Re: (Score:1)
Re: (Score:2)
There are tools to accomplish this (orms) but this is incredibly kludgy and a pain to maintain.
Really? Funny how I've never noticed. I've used several ORMs, recently Doctrine 2, and it's the opposite of pain.
I can have an easy to maintain database connection up in mongo immediately with zero impedance mismatch and rapid development. I can push "mongo" collection objects all the way up to the angular UI and back down to the database with almost zero coding. I was playing with a little app last night and wanted to add crud support. It took about 10 seconds to source the mongo driver and have the code complete.
There's also a mismatch between rapid development and production code. For my purposes, ORMs solve the gap perfectly. I don't know your use case, so I won't judge.
However, there is a big difference between prototypes and hacking up a quick app and doing something for serious production use. I see you understand that as well. I've just gone a step further - I prototype in Symfony2 with Doctrine2,
It's not just about being a document store (Score:1)
Re: (Score:2, Insightful)
References, please.
I have a feeling you can't produce anyway, because relational databases are still widely used.
Re:Nice touch but too late! (Score:5, Insightful)
By "industry" you mean the 0.001% of websites that could actually benefit from NoSQL?
How many sites you visit use NoSQL? Do most webshops, blogs, news sites and forums? Does Slashdot?
Re:Nice touch but too late! (Score:5, Insightful)
A small minority of companies, with very special needs, are using NoSql databases for a small proportion of their operations. Those companies do include some big ones, such as Google and Twitter, but still in absolute terms the numbers are small. A tiny minority of companies have moved away from relational databases altogether. But the numbers are statistically insignificant and are likely to remain so for decades. And the relational model does have some real and enduring benefits which will make it the right tool for many jobs far into the future.
Remember this is an industry that advances very slowly indeed. Your bank, and your utility companies, are still using programs written in COBOL - technology which is fifty years behind the curve.
Re: (Score:2)
I still need a list of these big sites that moved from SQL. No MySQL, no Postgre, no Hadoop...
Hadoop uses SQL? I don't think so.
Re: (Score:1)
You can use HIVE on Hadoop. It supports a subset of SQL.
You can't do everything with it, however. No in-equijoins, not much in the way of analytic support. But you can do joins, aggregations and some other stuff.
Still it's no replacement for a proper RDBMs when you want to get frisky with the queries. Hand writing map reduce jobs to do exactly what you need can be time consuming to write, and even more so to change with evolving requirements.
Re: (Score:2)
Re: (Score:2)
Nice touch but too late! (Score:5, Insightful)
I don't know whether angry tapir knows what relational means, but I see nothing in his post IMHO suggesting he has no clue. JSON is great for storing non-relational data (hierarchies, data without fixed set of columns, ...). Not all data are purely relational, it's often a mix.
Re: (Score:2)
(Todd Codd anyone?)
Close... acutally his name was Edgar Frank "Ted" Codd [wikipedia.org]
Mutt-hater! (Score:4, Funny)
No HalfSQL movement?
Re:If this is anything like MariaDB (Score:5, Informative)
I am actually *using* this thing. Implemented a database with ~100K XML records, access them by arbitrary XPATh expression.
Of course "normal" access is slow, but once I agree with the customer on an access pattern, I can set up a functional index. Then we are at a couple millisecs per access (on very low-end hardware). And with GIN indexes, I can even set up things like "find all records where tag A or tag B or tag C equal one of "foo" or "bar". All for a handful millisecs. No database tuning whatsoever -- plain vanilla PostgreSQL 9.1 as it comes to us with Debian.
Of course you can't compare it with -- say -- Elastic Search, but as soon as I finish uttering "Java" my box is out of memory :-)
OK, on a more serious note: the usage patterns still are different: if you plan to have 100M biggish records, you'll probably want to throw a lot of boxes at the problem (unless the problem has a very specific structure). Then you'll probably be better off with Elastic Search or some such. OTOH if you want transactions, an SQL database it is. If you need both, you are in a tough place (cf. CAP theorem), so you gotta think hard.
I don't fucking care whether it's called SQL or noSQL if it's well-done. And PostgreSQL is damn well done. The community rocks too.
Re:If this is anything like MariaDB (Score:4, Informative)
Well, yes and no. PostgreSQL had a text-only JSON data type since long time, and was able to index keys using expression indexes. That's nothing new.
The 9.4 improvements are that the (a) JSONB is stored in a binary form, and (b) a lot of ideas from HSTORE data type, plus new ones were implemented. That means that you can create "universal" index without prior knowledge of what keys will be interesting. So then you can ask for data containing arbitrary keys, sets of keys, values, documents etc. See http://www.postgresql.org/docs... [postgresql.org]
Sure, it's not perfect and the index may get somehow big, but well ...
Re: (Score:1, Informative)
Actually PostgreSQL performs a lot better than MySQL/MariaDB, and looks after your data better. PostgreSQL has far fewer gotcha's (no database is perfect!), and is not the mess that MySQL is.
People started migrating from Oracle to PostgreSQL at version 8.0 or earlier, and now PostgreSQL is at 9.4 beta. Companies like Digg initially went to MySQL because Master/multislave was in core for MYSQL - now as of 9.0, PostgreSQL has that too.
With PostgreSQL supporting JSON, it allows people to use the NoSQL paradi
Re: (Score:2)
Nothing. Because the postgres community didn't mean this to be "aim at the NoSQL market." The fact that angry tapir puts that into an abstract on ./ does not make it 'community opinion'.