Forgot your password?
typodupeerror
Data Storage Programming

New PostgreSQL Guns For NoSQL Market 162

Posted by samzenpus
from the coming-for-you dept.
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."
This discussion has been archived. No new comments can be posted.

New PostgreSQL Guns For NoSQL Market

Comments Filter:
  • by mlyle (148697) on Friday May 16, 2014 @12:50AM (#47015357)

    We just released Postgres-XL [postgres-xl.org] so you can have horizontal scalability and MPP.

  • by Anonymous Coward on Friday May 16, 2014 @01:20AM (#47015439)

    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.

  • by Anonymous Coward on Friday May 16, 2014 @01:30AM (#47015465)

    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 paradigm were it appears to be useful, without locking themselves out of a fully fledged relational database.

    If your data is important to you, and you might need some serious DB querying stuff, then PostgreSQL should be considered.

  • Re:next for NoSQL (Score:4, Informative)

    by bdares (1042128) on Friday May 16, 2014 @01:31AM (#47015471)
    "NoSQL" doesn't mean "No SQL". At least, not all the time. I've heard it pronounced "Not Only SQL" more than once. RDF triple stores can also be considered NoSQL databases, and they can provide ACID. (They use SPARQL instead of SQL as a query language - hence being something other than a SQL DB.)
  • by fuzzytv (2108482) on Friday May 16, 2014 @04:12AM (#47015807)

    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 ...

"Ahead warp factor 1" - Captain Kirk

Working...