I’m here at DjangoCon in Washington, DC and thinking about what it is that developers are currently excited about in Postgres.
Postgres hackers are often very focused on solving our own problems, problems people bring up on our mailing lists and dealing with database scaling, replication and data management.
Developers using Postgres seem more interested in the features which make creating applications easier and removing complexity from architecture.
So, what are they interested in?
The features that I hear mentioned most often include:
(thanks to @ipmb for the list in a lightning talk today!)
What are the features you hear about from developers? Or if you’re a web developer, what are your favorite features in PostgreSQL?
Above all, stability. The remaining legacy MySQL installations we still have running at work are causing me more sysadmin headaches than all our Postgres installations combined. I can *dream* the sequence “find /var/lib/mysql -exec myisamchk -r {} \;” by now (yeah, they’re nightmares)… Postgres just… runs.
But after that, the fact that Postgres can grow infinitely along with your application. We can throw any amount of data at it and it just soaks it up without breaking a sweat. Finally, I’ve become a big fan of Common Table Expressions (WITH clauses) and window functions!
As a developer my favourite features are:
* Transactional DDL
* LISTEN/NOTIFY
* The excellent support for temporal types and functions.
* Functional and conditional indexes
* psql — the best command line interface for a databse I have used. A pity that there is a lciense clash between OpenSSL and libreadline though.
1. Stability and data integrity
2. Minimal maintenance
3. Simple licensing
4. Easy extensibility, both through new types and embedded scripting
5. LISTEN/NOTIFY
6. Rich datatypes and a good planner and index support for them (full text search, ranges, ip addresses, …)
7. A command line interface that doesn’t suck
8. Transactional DDL
The best thing about PostgreSQL from a developer’s perspective is that they don’t need to care about their data. They know that their data is not truncated or garbled, its stored safely in the database, even if we crash – with redundant copies made using replication. When they request data from the database the optimizer works out the most efficient path, then gives them access to a consistent view of their data even while someone else is updating it at the same time. All of those things allows developers to concentrate on their job not on making the technology work. Obviously, we then have the problem that if developers don’t know about these things, there’s little perceived benefit – which is probably why your list is so very short. A problem of a different kind though, and one that indicates success in our main objectives.
Sugary syntax! Oracle and SQL Server and MySQL are all just so ugly. Every little thing requires yet another function call with it’s prerequisite opening and closing parens, which will make “some poor schmuck bounce on the % key in vi.”
Want to subtract two dates? In Postgres it’s one character. The subtract character. That’s probably 70% less characters than the other databases (DATEDIFF(), DATE_SUB(), etc.), it’s one less set of parens that you have to mentally match up, and most importantly, it’s just kind of obvious and simple.