ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

PostgreSQL and the NoSQL world

As I linked earlier today to the MemSQL and JSON story, I’ve thought again about PostgreSQL and its community approach of bringing in new features. It’s hard to miss what they are doing. And I think they are doing it right.

The PostgreSQL community is looking outside the box and listens. What features are users of NoSQL databases most excited about? Can we offer native support for them? Can we integrate with these other tools? These are the right questions to ask when considering expanding outside your space to help your users.

PostgreSQL 9.2 introduced a JSON data type and JSON functions and operators. Here’s what I wrote about when linking to a post about the augmented support for the JSON data type.

PostgreSQL 9.3 added a Javascript engine (V8) bringing even more power to the JSON data type. Also in PostgreSQL 9.3 there’s support for foreign data wrappers: a feature allowing to query from PostgreSQL external data sources.

While it might sound easy to watch what others are doing and then do it yourself—this is probably well-known as the Microsoft strategy—the reality is there’s a lot of complexity of following this strategy. Besides asking the right questions when picking what features to bring in, there are always the technical and design decisions:

  1. can we actually support this?
  2. can we support it in a way that’ll not break or impact negatively existing features?
  3. how should we expose these “imported” features so we make them appealing to existing users (with their vision of the product), while keeping them attractive and familiar to new users?

The last question is the most difficult to come with the right answers.

✚ Here’s also a post I’ve linked to showing how to use PostgreSQL as a schemaless database.

Original title and link: PostgreSQL and the NoSQL world (NoSQL database©myNoSQL)