Thursday, 1 April 2010

Postgres 9.1 - Release Theme

Following a great deal of discussion, I'm pleased to announce that the PostgreSQL Core team has decided that the major theme for the 9.1 release, due in 2011, will be 'NoSQL'.

There is a growing trend towards NoSQL databases, with major sites like Twitter and Facebook utilising them extensively. NoSQL databases often include multi-master replication, clustering and failover features that have long been requested in PostgresSQL, but have been extremely difficult to implement with SQL which has prevented us from advancing Postgree in the way that we'd like.

To address this, the intention is to remove SQL support from Postgres, and replace it with a language called 'QUEL'. This will provide us with the flexibility we need to implement the features of modern NoSQL databases. With no SQL support there will obviously be some differences in the query syntax that must be used to access your data. For example, the query:

select (e.salary/ (e.age - 18)) as comp from employee as e where = "Jones"

would be rewritten as:

range of e is employee retrieve (comp = e.salary/ (e.age - 18)) where = "Jones"

Aggregate syntax in QUEL is particularly powerful. For example, the query:

select dept,
avg(salary) as avg_salary,
sum(salary) as tot_salary
group by

may be written as:

range of e is employee
retrieve (e.dept,
avg_salary = avg(e.salary by e.dept),
tot_salary = sum(e.salary by e.dept)

Note that the grouped column can be specified for each individual aggregate.

We will be producing a comprehensive guide to the QUEL syntax to aid with application migration. We appreciate the difficulty that this change may cause some users, but feel we must embrace the NoSQL philosophy in order to remain "The world's most advanced Open Source

"There's no question that, at 21 years old, the SQL standard is past its prime," said core developer and standards expert Peter Eisentraut. "It's time for us to switch to something fresher. I personally would have preferred XSLT, but QUEL is almost as good."

Project committer Heikki Linnakangas added: "By replacing SQL with QUEL not only will will be able to add new features to Postgres that were previously too difficult, but we'll also increase user loyalty as it'll be much harder for them to change to a different, SQL-based
database. That'll be pretty cool."

You may also notice that without SQL, the project name is somewhat misleading. To address that, the project name will be changed to 'PostgreQUEL' with the 9.1 release. We expect this will also put an end to the periodic debates on changing the project name.

Dave Page
On behalf of the PostgreSQL Core Team


  1. Even though it is frustrating, I am pleased to change that we are following trends.

  2. Hi Dave,

    I understand the fact that QUEL is more expressive and simple than SQL, But i don't really understand how QUEL can help to resolve a problem likes multi-master replication ? thanks to the integrated command "COPY" ?

    Can you tell us more about that ?

  3. Hi Amine,

    Please check the date of the post.

  4. Wouldn't it be more believable if PG switched to XPath instead?

    Enjoy your April 1st, everyone

  5. This is the best news ever. I understand that some developers are started working on this. With this new change we can reduce many many unused PostgreSQL functionality and finally compete with sqlite.

  6. *yawn* MySQL has had this feature for years.

  7. I want a JSON/JQuery interface. I, like most people I know use PostgreSQL mostly for manipulating data in javascript. I fail to see how this implementation of NoSQL helps us achieve this goal.

    Not to say JSON is all that is needed. We obviously need a pluggable QUEL interface to satisfy the needs of our growing research community. We need xpath and some sort of matrix QUEL to allow doing calculations across columns efficient so that my dream of a 10,000 column table can be achieved efficiently.

  8. LOL,

    OUPS, I forget that we are 1 april.

  9. An obvious case where less is more.

  10. It's evolution, noSql will rule the world!

  11. Um, cleartext ASCII data and index files would also be great, imagine the type flexibility of SQLite with the extended data manipulation possibilities of QUEL topped by notepad-enabled disaster recovery - what a dream!

  12. Will this update require to recompile? I hope not.

    -- Stephan

  13. A timely move :-) For more information on the superiority of NoSQL (QUEL) over SQL, read the essay by Christopher Charles "My Brilliant Career Tuning SQL" at

  14. will the new version support emoticons as a datatype?

  15. Geez, I almost had a heart attack.

    Good one!

  16. old (as in ancient) INGRES hacks the world over will rejoice

  17. Too bad that this is a joke. In 1987, I graduated Cooper Union, I worked at Citibank in Funds Transfer and I was programming in QUEL on a Commercial Ingres system. Having learned both relational algebra and calculus in school, I was pleased to be able to use the more expressive calculus. Alas, it was not meant to be. Citi started cutting over to Oracle. In then left. A few years (and jobs) later I started working with Sybase. In SQL. It took me weeks to understand how to use the algebra again. We'd go a long way if this post were NOT a joke.

  18. This must have been the best April fools joke ... It is the only one that tricked me today. Good job guys :)

  19. Seriously, I think "SQL" should be removed from the project name; the older name "Postgres" is much better. The technology is capable both now and extendable to support multiple query languages, not just SQL, and the project name shouldn't imply SQL-only. Maybe the name was changed awhile ago to help Postgres get mind share, but it has lots of mind share now, so that is no longer needed. Any good DBMS, regardless of whether or not it uses SQL, shouldn't have "SQL" in its name; that is a limiter. And there's the whole harder-to-write/pronounce/etc thing.

  20. Good God, I got totally punked!

  21. funny!

    but also missing the point that much of nosql is about 'no set theory' not 'replacing sql'

  22. It's about time that all former SQL database projects realized how terribly SQL sucks and dropped the language,
    no pun intended.

  23. Jeez, you almost got me! My heart started to pound when I tried to add up all of the hours I'd have to spend learning a new query language syntax! Nice one!


  24. ara: Yes, missing the point of what NoSQL is was part of the joke. As was the numerous mis-spellings of Postgres/PostgreSQL. And Heikki's comment about locking users in, and the bit about the 'new' project name (though actually, I think PostgreQUEL does have a certain ring to it). And Peter's preference for XSLT.

    It was intended as a quip on many levels, something for the whole family!

  25. Damn, I was duped too! Good one man, good one!

  26. Tsktsktsk, you forgot to ask Stonebraker to do the QUEL spiel.
    Would have been almost beliavable then!

  27. Is it April fool? If so, I'm disappointed. I was really supprised and excited when I saw the news because I received the mail on April 2 in my country.
    I really want PostgreSQL to:

    (1) separate the storage engine cleanly and provide key-value access API like MySQL's storage engines. As API, Berkeley DB seems good.

    (2) provide distributed, scalable cloud-ready RDBMS and key-value stores. Key-value interface makes it difficult to build complex data manipulations. However, it is better than SQL in that it provides flexible data model (no predefined schema) and faster response time.

  28. Will it come with GPU acceleration ?

  29. Yeh...Best of 1st April...!! Like it. QUEL is Cool..!!

  30. Good marketing move, by the way, PostgresQUEL pronounces the same.

    But what is wanted to ask is how are you planning to prepare for the upcoming NoQUEL fad?

  31. Is it a joke???
    Oh God! I've been 7 days replacing all my queries!!!