Postgres Advances to Meet NoSQL

Challenges

An EnterpriseDB
White Paper
For DBAs, Database
Architects & IT Directors
April 2014

Postgres Advances to Meet NoSQL Challenges

Table of Contents

Introduction

Relational vs. NoSQL

Trade-offs with NoSQL

Postgres Capabilities for NoSQL Workloads

Document Database JSON

Key-value Store

Non-durable Tables

Scalability

Benefits of Staying with SQL

Postgres: The Best of Both Worlds

10

About EnterpriseDB

11

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 2

Postgres Advances to Meet NoSQL Challenges

Introduction
Data has changed. Bigger volumes, needs for faster processing and
new data types mean organizations today are facing new problems. Big
Data problems. In response, many organizations have begun to ask
whether they need a new solution, such as a NoSQL solution, to
augment the capabilities of their longstanding relational databases to
solve their new problems.
Celebrated NoSQL use cases at major technology brands, like
Amazon, Facebook and Twitter, as well as clever marketing efforts by
emerging NoSQL solution providers have convinced many companies
they need something new.
Most Postgres users, however, do not.
Postgres has advanced significantly in recent releases. With new
features and capabilities alongside several longstanding components
and extensions, Postgres can support virtually all of todays data types
as well as unstructured and semi-structured data. This is meaningful for
two reasons:
1. Postgres can power many applications written for NoSQL
technologies.
2. Developers can build applications in Postgres that achieve the
same results as NoSQL solutions.

Relational vs. NoSQL

Its important to note that NoSQL is not one thing. Its an umbrella term
for different niche technologies, each addressing a single problem. The
four most prominent NoSQL technologies most often referenced in Big
Data conversations are:

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 3

Postgres Advances to Meet NoSQL Challenges

Key-value stores
Document databases
Column stores
Graph databases

Of these, the technologies that address the most common kinds of

challenges are key-value stores and document databases.
Most NoSQL variants solve legitimate business data processing
problems and deserve a place in some database architectures. They
support analytics when the data loads are massive, such as loads that
exceed 100s of terabytes. Companies also looked to NoSQL for
transactional applications that could support new data types and new
ways to store and work with them. Relational technologies are
advancing on the data load threshold and already can support some
NoSQL capabilities (as you will learn) while evolving quickly addressing
others.
But first understand that NoSQL technologies support these specialized
applications by sidestepping the use of a powerful query language, a
sophisticated query optimizer, data normalization, joins, referential
integrity and durability. They had to do this to achieve high rates of
processing speed; data, meanwhile, had to be simple and isolated.
In other words, NoSQL technologies ditched many of the
features and capabilities that people had wanted when relational
database technologies were developed in the first place.
Keep in mind that relational databases were developed to replace
disparate, niche technologies that had been used to solve very specific
problems.

Trade-offs with NoSQL

Organizations using NoSQL need to recognize how the technology
trade-offs in NoSQL affect their business. Fundamental differences

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 4

Postgres Advances to Meet NoSQL Challenges

between NoSQL and relational technologies contribute to greater
operational challenges.
NoSQL expertise is expensive. NoSQL is not a database standard.
Each NoSQL database uses a different representation for its data and
its data access/manipulation language, which are directly related to the
problem each is trying to solve.
NoSQL skills are hard to come by, expensive to obtain and not
portable.
Applications have to do the heavy lifting. NoSQL technologies store
data. They dont process the data. Because NoSQL technologies dont
have aggregates or data analysis functions, data must be brought to
the application for analysis. As a result, applications have to perform
much of the processing that with Postgres is done in the database.
Reporting, for example, is especially difficult with NoSQL applications.
Applications to support enterprise operations are much more
complex.
Application processing introduces operational challenges.
Schema-less data requires complex client-side knowledge of the data
for processing. Further, without a powerful query language and a query
optimizer, the application (and hence the individual application
developer) is responsible for efficiently accessing data and for data
consistency. This situation is further exacerbated by the lack of a
standard NoSQL language its anybody's guess as to the best practice
for solving processing challenges.
This introduces inconsistency in processing techniques and
performance across applications as well as maintenance difficulties
across applications. Applications developed in NoSQL have also led to
data silos within the infrastructure, adding maintenance and
management complexity.
Disparate technologies mean differences in application
performance, maintenance demands and data management.
Complex workarounds to achieve ACID compliance put more

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 5

Postgres Advances to Meet NoSQL Challenges

responsibility for data integrity on the DBA. NoSQL technologies

are not ACID compliant. More and more users are discovering this
limitation and the consequence is that developers and DBAs must build
complex workarounds.
This calls for a very sophisticated level of expertise in that particular
flavor of NoSQL and a great deal of application-specific programmer
knowledge.
As a result, DBAs end up having to rely on the application to ensure the
data theyre charged with protecting retains its integrity. This introduces
a significant amount of risk, and it brings additional complexity and
overall management challenges to the infrastructure even if you
create best practices, how do you enforce them and standardized
frameworks amongst all your developers?
Without data integrity controls baked into the database,
database administrators shoulder the responsibility of whether
the applications ensure ACID compliance.

Postgres Capabilities for NoSQL Workloads

There are capabilities in Postgres that enable it to achieve much of
what NoSQL technologies have been designed to do. Postgres was
originally architected to be an object-relational database designed
specifically to be extensible. It supports objects and classes and
custom data types and methods. In the early years of the Postgres
project this was problematic as it slowed down development cycles;
new code had to be fully integrated so everything would work with
everything else.
However, as Postgres has become more feature rich over the past 15
years, that original design hurdle has turned into a unique advantage.
The fact that Postgres is an object-relational database means new
capabilities could be developed as needs evolved and plugged into the
database seamlessly. Using this level of extensibility, Postgres
developers were able to build new features and capabilities as needs
emerged. The perfect examples are JSON for document storage

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 6

Postgres Advances to Meet NoSQL Challenges

support and HStore for key-value support.
In comparison to NoSQL technologies, the two most important
extensions for Postgres users are these document database and keyvalue store functionality.
With JSON and HStore, Postgres can support applications that
require a great deal of flexibility in how data is handled.

Document Database - JSON

Document database capabilities in Postgres advanced significantly
when support for the JSON data type was introduced in v9.0. JSON
(JavaScript Object Notation) is one of the most popular datainterchange formats on the web. It is supported by virtually every
programming language in use today, and continues to gain traction
through the introduction of new supporting technologies such as the
PL/V8 Javascript (also supported in Postgres) and PL/Coffee V8
programming extensions and Node.js. Some NoSQL systems, such as
MongoDB, use JSON as their native data interchange format.
Postgres offers robust support for JSON. Postgres has a JSON data
type, which validates and stores JSON text and provides functions for
extracting elements from JSON values. And, it offers the ability to easily
encode query result sets using JSON. This last piece of functionality is
particularly important, as it means that applications that prefer to work
natively with JSON can easily obtain their data from Postgres in JSON.
In addition to the native JSON data type, Postgres v9.3 added a JSON
parser and a variety of JSON functions. This means web application
developers don't need translation layers in the code between the
database and the web framework that uses JSON. JSON-formatted
data can be sent directly to the database where Postgres will not only
store the data, but properly validate it as well. With JSON functions,
Postgres can read relational data from a table and return it to the
application as valid JSON formatted strings. And, the relational data
can be returned as JSON for either a single value or an entire record.
There are also functions that convert Postgres-maintained key-value
data (by means of the HStore contrib modulesee below) to JSONformatted data, which increases the flexibility and scope of NoSQL-like

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 7

Postgres Advances to Meet NoSQL Challenges

applications that can be addressed by Postgres. In summary, the JSON

data, operator and function enhancements mean that developing
NoSQL-like applications is much easier.
Finally, v9.4 of Postgres scheduled for release in the fall of 2014 has
added the ability to store JSON in a binary format with index support
creating processing speeds that for many use cases out-perform the
more popular NoSQL document store engines.

Key-value Store HStore

The HStore contrib module, which can store key/value pairs within a
single column, enables users to create a schema-less key-value store.
But unlike pure NoSQL solutions, a key-value store created in Postgres
is ACID compliant.
HStore is a particularly handy tool for web developers or
someone building an application that requires the ACID
properties of Postgres and NoSQL capabilities.
HStore pre-dates many NoSQL advances. It was introduced in v8.2
in 2006, pre-dating many NoSQL advances. Its popularity surged in
recent years with new demands for working with semi-structured data.
HStore is not hierarchical, but the HStore data type offers advanced
indexing support, which makes it the solution of choice for many
applications. It is particularly useful for data with sparsely populated
attributes. Instead of creating a large number of columns, each of
which will be non-null for only a small percentage of the records in the
table, database administrators can create a single HStore column and
include, for each row, only those keys which pertain to that record.
For instance, this is quite useful for storing multiple product
descriptions in a single table where each product only shares a few
attributes, like name, price and weight, but have many different
attributes based on the type of product, such as size for shoes, CPU for
a laptop. It is also useful in cases where new attributes may need to be
added on the fly.
Again like JSON, it can be used to emulate a schema-less database
when that is desirable. Ultimately, this fills a unique need in relational
table storage by not requiring additional space for attributes that will

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 8

Postgres Advances to Meet NoSQL Challenges

never have a value for many records. It allows database administrators
to store very different types of records with different attributes in the
same table, and query them using SQL.

Non-durable Tables
Postgres also has the capacity to sacrifice some data durability to
enhance performance. In v9.2, Postgres introduced unlogged tables
(which in the NoSQL world are called non-durable tables). This means
that in order to get better application performance, users can prioritize
data, and designate some data sets whose loss is acceptable should a
crash occur.

Scalability
The sharding capability of some NoSQL technologies is considered
particularly useful, but only in very limited circumstances. Postgres,
meanwhile, achieves the same goal but at the application level, and
there are benefits to this approach.
Sharding in NoSQL variants enable the solution to automatically
manage horizontal scalability so that the database, though spread
across multiple machines, appears as one database. Achieving the
benefits of sharding in Postgres simply requires writing application
instructions for locating the data spread across multiple machines.
This makes sense for users who, for example, need to split up data
geographically so that data is closer to the people who most use it, or
for applications that split up data using a time element so that older
data is easily disposed of in bulk. This is a straightforward process in
Postgres and addresses many of the needs that users articulate when
they think they need a NoSQL solution to leverage sharding.

Benefits of Staying with SQL

There are multiple reasons why enterprise data professionals should
look deeper into their Postgres database for NoSQL answers instead of
ushering in an edge-case solution, no matter what the promise. Several
were mentioned above, such as the difficulty and cost of acquiring the

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 9

Postgres Advances to Meet NoSQL Challenges

proper skill set as well as greater complexity, from application

development to overall data maintenance and infrastructure
management.
SQL-aware development tools, reporting tools, monitoring tools and
connectors are available for just about every combination of operating
system, platform and database under the sun, and nearly every
programmer or IT professional has at least a passing familiarity with
SQL syntax. Even for relatively simple queries that are likely to be
practical on huge data stores, writing an SQL query is typically simpler
and faster than writing an algorithm to compute the desired answer, as
is often necessary for data stores that do not include a query language.
Production applications sometimes require only primary key lookups,
but reporting queries often need to filter or aggregate based on other
columns. Document databases and distributed key-value stores
sometimes don't support this at all, or they may support it only if an
index on the relevant column has been defined in advance.
In addition, document databases and distributed key-value stores have
different interfaces, offer different isolation and durability guarantees,
and accept very different types of queries. Changing between systems
promises to be challenging.

Postgres: Best of Both Worlds

Relational databases are and will continue to be the day-to-day
workhorses for mission-critical applications that must adhere to ACID
properties. Relational table storage and the SQL language are well
understood and optimized standards of relational databases, and the
skills are transportable across SQL databases and well known by a
large pool of developers with decades of broad market support.
The ability of Postgres to support key-value stores within the database
as well as document databases empower users to address expanding
demands using the skills and tools with which they are already familiar.
Exploring new capabilities within Postgres to address more data
problems instead of turning to new solutions ultimately means lower

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 10

Postgres Advances to Meet NoSQL Challenges

costs, less risk and less complexity while delivering enterprise-class
workloads with ACID compliance.
Further, SQL databases will continue to evolve.
SQL databases like Postgres are closing the gap that motivated
the rise and development of NoSQL technologies, and will
continue to provide capabilities that NoSQL technologies simply
cannot.
The successful relational database of today and the future will be able
to integrate and federate data from multiple external systems and in
multiple formats including NoSQL varieties of databases. Recognition
of long-standing capabilities that have new uses and continuing
advances will enable Postgres to play a significant role in the data
center even as new data challenges emerge.
Get Started Today. Let EnterpriseDB help you address your emerging
data demands with Postgres. Contact us at +1-877-377-4352 or +1781-357-3390, or send an email to sales@enterprisedb.com to get
started.

About EnterpriseDB
EnterpriseDB is the leading worldwide provider of Postgres software
and services that enable enterprises to reduce their reliance on costly
proprietary solutions and slash their database spend by 80 percent or
more. With powerful performance and security enhancements for
PostgreSQL, sophisticated management tools for global deployments
and Oracle compatibility, EnterpriseDB software supports both mission
and non-mission critical enterprise applications. More than 2,400
enterprises, governments and other organizations worldwide use
EnterpriseDB software, support, training and professional services to
integrate open source software into their existing data infrastructures.
Based in Bedford, MA, EnterpriseDB is backed by top-tier venture
capitalists and strategic investors like Red Hat and IBM. For more
information, please visit http://www.enterprisedb.com/.
20140430

2014 EnterpriseDB Corporation. All rights reserved. EnterpriseDB and Postgres Plus are trademarks of
EnterpriseDB Corporation. Other names may be trademarks of their respective owners.
http://www.enterprisedb.com
Page: 11