52 COMMUNICATIONS OF THE ACM | JULY 2008 | VOL. 51 | NO. 7
practice
THE NUMBER AND VARIETY of computing devices in the
environment are increasing rapidly. Real computers
are no longer tethered to desktops or locked in server
rooms. PDAs, highly mobile tablet and laptop devices,
palmtop computers, and mobile telephony handsets
now offer powerful platforms for the delivery of new
applications and services. These devices are, however,
only the tip of the iceberg. Hidden from sight are the
many computing and network elements required to
support the infrastructure that makes ubiquitous
computing possible.
With so much computing power traveling around
in briefcases and pockets, developers are building
applications that would have been impossible just a
few years ago. Among the interesting services available
today are text and multimedia messaging, location-
based search and information services (for example,
on-demand reviews of nearby restau-
rants), and ad hoc multiplayer games.
Over the next several years, new classes
of mobile and personalized services,
impossible to predict today, will cer-
tainly be developed.
While these services differ from one
another in major ways, they also share
some important attributes. One—the
focus of this article—is the need for
data storage and retrieval functions
built into the application. Messaging
applications need to move messages
around the network reliably and with-
out loss. Location-based services need
to map physical location to logical lo-
cation (for example, GPS or cell-tower
coordinates to postal code) and then
look up location-based information.
Gaming applications must record and
share the current state of the game on
distributed devices and must manage
content retrieval and delivery to each
of the devices in real time. In all these
cases, fast, reliable data storage and re-
trieval are critical.
As soon as the discussion turns to
data storage and retrieval, relational
databases come to mind. Relational
databases have been tremendously
successful over the past three decades
and SQL has become the lingua franca
for data access. While data manage-
ment has become almost synonymous
with RDBMS, however, there are an
increasing number of applications for
which lighter-weight alternatives are
more appropriate.
This article begins with a brief re-
view of how relational systems came to
dominate the data management land-
scape, and discusses how the relational
technologies have evolved. It presents
a data-centric overview of today’s emer-
gent applications, and delves into data
management needs for today’s and to-
morrow’s applications.
Relational Prehistory
Relational databases came out of re-
search at IBM
1,5
and the University of
California at Berkeley
7
in the 1970s. Re-
lational databases were fundamentally
a reaction to escalating costs in deploy-
Beyond
Relational
Databases
DOI: 10.1145/1364782.1364797
There is more to data access than SQL.
BY MARGO SELTZER

practice
JULY 2008 | VOL. 51 | NO. 7 | COMMUNICATIONS OF THE ACM 53
related trends emerged. First, the RD-
BMS vendors increased functionality
to provide market differentiators and
to address each new market niche as
it arose. Second, few applications need
all the features available in today’s
RDBMSs, so as the feature set size in-
creased, each application used a de-
creasing fraction of that feature set.
This drive toward increasing DBMS
functionality has been accompanied
by increasing complexity, and most
deployments now require a specialist,
trained in database administration,
to keep the systems and applications
running. Since these systems are devel-
oped and sold as monolithic entities,
even though applications may require
only a small subset of the system’s
functionality, each installation pays
the price of the total overall complexity.
Surely, there must be a better way.
ing and maintaining complex systems.
The key observation was that pro-
grammers, who were very expensive,
had to rewrite large amounts of appli-
cation software manually whenever the
content or physical organization of a
database changed. Because the appli-
cation generally knew in detail how its
data was stored, including its on-disk
layout, reorganizing databases or add-
ing new information to existing data-
bases forced wholesale changes to the
code accessing those databases.
Relational databases solved this
problem in two ways. First, they hid the
physical organization of the database
from the application and provided only
a logical view of the data. Second, they
used a declarative language to describe
the data of interest in a particular que-
ry, rather than forcing the programmer
to write a collection of function calls
to fetch the data. These two changes
allowed programmers to describe the
information they wanted and to leave
the details of optimization and access
to the database management system.
This transformation relieved program-
mers of the burden of rewriting appli-
cation code whenever the database lay-
out or organization changed.
Relational databases enjoyed tre-
mendous success in the IT shops and
data centers of the world. Businesses
with large quantities of data to manage
and sophisticated applications using
that data adopted the new technology
quickly. Demand for relational prod-
ucts created a market worth billions of
dollars in licensing revenue per year.
Several RDBMS vendors arose in the
1980s to compete for this lucrative
business.
In the 20 years that followed, two I
L
L
U
S
T
R
A
T
I
O
N

B
Y

C
E
L
I
A

J
O
H
N
S
O
N