SQLite

Developer(s) D. Richard Hipp

Initial release August 2000
3.7.3 / October 8, 2010; 53
Stable release
days ago
Written in C
Operating system Cross-platform
Size ~275 kiB
Type RDBMS (embedded)
License Public domain[1]
Website http://sqlite.org/

SQLite is an ACID-compliant embedded relational database management system

contained in a relatively small (~275 kiB)[4] C programming library. The source
code for SQLite is in the public domain[1][5] and implements most of the SQL
standard. In contrast to other databases, SQLite is not a separate process that is
accessed from the client application, but an integral part of it. It has a small core
and is much faster than other databases.[citation needed] This makes it interesting for
embedded systems.

SQLite uses a dynamically- and weakly-typed SQL syntax that does not guarantee
the domain integrity, which gives rise to criticism. SQLite is a multitasking
database concerning reads. Writes can be done only one-at-a-time. It is a popular
choice for local/client storage on Web browsers. It has many bindings to
programming languages. Before a new version is released, excessive regression
tests are performed, increasing the quality of the product. It is probably the most
widely used database engine, as it is used today by every instance of several
widespread browsers, operating systems, embeded systems among others.[6]

Design

Unlike client–server database management systems, the SQLite engine has no

standalone processes with which the application program communicates. Instead,
the SQLite library is linked in and thus becomes an integral part of the application
program. The library can also be called dynamically. The application program
uses SQLite's functionality through simple function calls, which reduce latency in
database access - function calls within a single process are more efficient than
inter-process communication. SQLite stores the entire database (definitions,
tables, indices, and the data itself) as a single cross-platform file on a host
machine. It implements this simple design by locking the entire database file
during writing.

History

D. Richard Hipp designed SQLite in the spring of 2000 while working for General
Dynamics on contract with the United States Navy.[7] Hipp was designing software
used on board guided missile destroyer ships, which were originally based on HP-
UX with an IBM Informix database back-end. The design goals of SQLite were to
allow the program to be operated without database installation or administration.
In August 2000, version 1.0 of SQLite was released, based on gdbm (GNU
Database Manager). SQLite 2.0 replaced gdbm with a custom B-tree
implementation, adding support for transactions. SQLite 3.0, partially funded by
America Online, added internationalization, manifest typing, and other major
improvements.

Features

SQLite implements most of the SQL-92 standard for SQL but it lacks some
features. For example it has partial support for triggers, and it can't write to
views. While it supports complex queries, it still has limited ALTER TABLE support,
as it can't modify or delete columns.[8]

SQLite uses an unusual type system for an SQL-compatible DBMS. Instead of

assigning a type to a column as in most SQL database systems, types are
assigned to individual values; in language terms it is dynamically typed.
Moreover, it is weakly typed in some of the same ways that Perl is: one can insert
a string into an integer column (although SQLite will try to convert the string to
an integer first, if the column's preferred type is integer). This adds flexibility to
columns, especially when bound to a dynamically typed scripting language.
However, the technique is not portable to other SQL databases. The inability to
have the domain integrity coming from statically typed columns, as in typical
databases, is a common criticism. The SQLite web site describes a "strict affinity"
mode, but this feature has not yet been added.[9] However, it can be implemented
with constraints like CHECK(typeof(x)='integer').[7]

Several computer processes or threads may access the same database without
problems. Several read accesses can be satisfied in parallel. A write access can
only be satisfied, if no other accesses are currently being serviced. Otherwise, the
write access fails with an error code (or can automatically be retried until a
configurable timeout expires). This concurrent access situation would change
when dealing with temporary tables.
A standalone program called sqlite3 is provided that can be used to create a
database, define tables within it, insert and change rows, run queries and
manage a SQLite database file. This program is a single executable file on the
host machine. It also serves as an example for writing applications that use the
SQLite library.

SQLite is a popular choice for local/client SQL storage within a web browser and
within a rich internet application framework;[10] most notably the leaders in this
area (Google Gears,[11] Adobe AIR,[12] and Firefox[13]) embed SQLite.

SQLite full unicode support is optional.[14]

SQLite also has bindings for a large number of programming languages, including
BASIC, C, C++, Clipper, Common Lisp, C#, Curl, Delphi, Haskell, Java, Lua,
newLisp, Objective-C (on Mac OS X and iPhone), OCaml, Perl, PHP, Pike, Python,
[15]
REBOL, R, Ruby,[16] Scheme, Smalltalk, Tcl and Visual Basic. There is also a
COM (ActiveX) wrapper making SQLite accessible on Windows to scripted
languages such as Javascript and VBScript. This adds database capabilities to
HTML Applications (HTA).[17]

SQLite has automated regression testing prior to each release.[18] Over 2 million
tests are run as part of a release's verification. Starting with the August 10, 2009
release of SQLite 3.6.17, SQLite releases have 100% branch test coverage, one
of the components of code coverage.

Development

SQLite development stores revisions of its source code in Fossil, a distributed

version control system that is itself built upon a SQLite database.[19]

Adoption

Mozilla Firefox and Mozilla Thunderbird store a variety of configuration data

(bookmarks, cookies, contacts etc.) in internally managed SQLite databases, and
even offer an add-on to manage SQLite databases. Skype is another widely
deployed application that uses SQLite.[20] Adobe Systems uses SQLite as its file
format in Adobe Photoshop Lightroom, a standard database in Adobe AIR, and
internally within Adobe Reader.[21] Ruby on Rails' default database is also SQLite.
Xmarks, the bookmark sharing tool has also reported to use SQLite to manage
the bookmarks for each user.[22] The Opera Internet suite and browser uses
SQLite 3.6.23 for managing WebSQL databases. This is noted in opera:about,
although without the mention of WebSQL (databases can be managed through
opera:webdatabases) The Service Management Facility, used for service
management within the Solaris and OpenSolaris operating systems, uses SQLite
internally.

Due to its small size, SQLite is well suited to embedded systems, and is also
included in Apple's iOS (where it is used for the SMS/MMS, Calendar, Call history
and Contacts storage), Symbian OS, Nokia's Maemo, Google's Android, RIM's
BlackBerry, Linux Foundation's MeeGo and Palm's webOS.[23] However, it is also
suitable for desktop operating systems; Apple adopted it as an option in Mac OS
X's Core Data API from the original implementation in Mac OS X 10.4 onwards,
and also for administration of videos and songs on the iPhone.

Distinctive Features Of SQLite

This page highlights some of the characteristics of SQLite that are unusual and
which make SQLite different from many other SQL database engines.

Zero-Configuration

SQLite does not need to be "installed" before it is used. There is no "setup"

procedure. There is no server process that needs to be started, stopped, or
configured. There is no need for an administrator to create a new database
instance or assign access permissions to users. SQLite uses no configuration files.
Nothing needs to be done to tell the system that SQLite is running. No actions are
required to recover after a system crash or power failure. There is nothing to
troubleshoot.

SQLite just works.

Other more familiar database engines run great once you get them going. But
doing the initial installation and configuration can be intimidatingly complex.

Serverless

Most SQL database engines are implemented as a separate server process.

Programs that want to access the database communicate with the server using
some kind of interprocess communication (typically TCP/IP) to send requests to
the server and to receive back results. SQLite does not work this way. With
SQLite, the process that wants to access the database reads and writes directly
from the database files on disk. There is no intermediary server process.

There are advantages and disadvantages to being serverless. The main

advantage is that there is no separate server process to install, setup, configure,
initialize, manage, and troubleshoot. This is one reason why SQLite is a "zero-
configuration" database engine. Programs that use SQLite require no
administrative support for setting up the database engine before they are run.
Any program that is able to access the disk is able to use an SQLite database.

On the other hand, a database engine that uses a server can provide better
protection from bugs in the client application - stray pointers in a client cannot
corrupt memory on the server. And because a server is a single persistent
process, it is able control database access with more precision, allowing for finer
grain locking and better concurrency.

Most SQL database engines are client/server based. Of those that are serverless,
SQLite is the only one that this author knows of that allows multiple applications
to access the same database at the same time.

Single Database File

An SQLite database is a single ordinary disk file that can be located anywhere in
the directory hierarchy. If SQLite can read the disk file then it can read anything
in the database. If the disk file and its directory are writable, then SQLite can
change anything in the database. Database files can easily be copied onto a USB
memory stick or emailed for sharing.

Other SQL database engines tend to store data as a large collection of files. Often
these files are in a standard location that only the database engine itself can
access. This makes the data more secure, but also makes it harder to access.
Some SQL database engines provide the option of writing directly to disk and
bypassing the filesystem all together. This provides added performance, but at
the cost of considerable setup and maintenance complexity.

Stable Cross-Platform Database File

The SQLite file format is cross-platform. A database file written on one machine
can be copied to and used on a different machine with a different architecture.
Big-endian or little-endian, 32-bit or 64-bit does not matter. All machines use the
same file format. Furthermore, the developers have pledged to keep the file
format stable and backwards compatible, so newer versions of SQLite can read
and write older database files.

Most other SQL database engines require you to dump and restore the database
when moving from one platform to another and often when upgrading to a newer
version of the software.

Compact
When optimized for size, the whole SQLite library with everything enabled is less
than 275KiB in size (as measured on an ix86 using the "size" utility from the GNU
compiler suite.) Unneeded features can be disabled at compile-time to further
reduce the size of the library to under 190KiB if desired.

Most other SQL database engines are much larger than this. IBM boasts that its
recently released CloudScape database engine is "only" a 2MiB jar file - an order
of magnitude larger than SQLite even after it is compressed! Firebird boasts that
its client-side library is only 350KiB. That's 50% larger than SQLite and does not
even contain the database engine. The Berkeley DB library from Oracle is 450KiB
and it omits SQL support, providing the programmer with only simple key/value
pairs.

Manifest typing

Most SQL database engines use static typing. A datatype is associated with each
column in a table and only values of that particular datatype are allowed to be
stored in that column. SQLite relaxes this restriction by using manifest typing. In
manifest typing, the datatype is a property of the value itself, not of the column
in which the value is stored. SQLite thus allows the user to store any value of any
datatype into any column regardless of the declared type of that column. (There
are some exceptions to this rule: An INTEGER PRIMARY KEY column may only
store integers. And SQLite attempts to coerce values into the declared datatype
of the column when it can.)

As far as we can tell, the SQL language specification allows the use of manifest
typing. Nevertheless, most other SQL database engines are statically typed and
so some people feel that the use of manifest typing is a bug in SQLite. But the
authors of SQLite feel very strongly that this is a feature. The use of manifest
typing in SQLite is a deliberate design decision which has proven in practice to
make SQLite more reliable and easier to use, especially when used in combination
with dynamically typed programming languages such as Tcl and Python.

Variable-length records

Most other SQL database engines allocated a fixed amount of disk space for each
row in most tables. They play special tricks for handling BLOBs and CLOBs which
can be of wildly varying length. But for most tables, if you declare a column to be
a VARCHAR(100) then the database engine will allocate 100 bytes of disk space
regardless of how much information you actually store in that column.

SQLite, in contrast, use only the amount of disk space actually needed to store
the information in a row. If you store a single character in a VARCHAR(100)
column, then only a single byte of disk space is consumed. (Actually two bytes -
there is some overhead at the beginning of each column to record its datatype
and length.)

The use of variable-length records by SQLite has a number of advantages. It

results in smaller database files, obviously. It also makes the database run faster,
since there is less information to move to and from disk. And, the use of variable-
length records makes it possible for SQLite to employ manifest typing instead of
static typing.

Readable source code

The source code to SQLite is designed to be readable and accessible to the

average programmer. All procedures and data structures and many automatic
variables are carefully commented with useful information about what they do.
Boilerplate commenting is omitted.

SQL statements compile into virtual machine code

Every SQL database engine compiles each SQL statement into some kind of
internal data structure which is then used to carry out the work of the statement.
But in most SQL engines that internal data structure is a complex web of
interlinked structures and objects. In SQLite, the compiled form of statements is
a short program in a machine-language like representation. Users of the database
can view this virtual machine language by prepending the EXPLAIN keyword to a
query.

The use of a virtual machine in SQLite has been a great benefit to the library's
development. The virtual machine provides a crisp, well-defined junction between
the front-end of SQLite (the part that parses SQL statements and generates
virtual machine code) and the back-end (the part that executes the virtual
machine code and computes a result.) The virtual machine allows the developers
to see clearly and in an easily readable form what SQLite is trying to do with each
statement it compiles, which is a tremendous help in debugging. Depending on
how it is compiled, SQLite also has the capability of tracing the execution of the
virtual machine - printing each virtual machine instruction and its result as it
executes.

Public domain

The source code for SQLite is in the public domain. No claim of copyright is made
on any part of the core source code. (The documentation and test code is a
different matter - some sections of documentation and test logic are governed by
open-source licenses.) All contributors to the SQLite core software have signed
affidavits specifically disavowing any copyright interest in the code. This means
that anybody is able to legally do anything they want with the SQLite source
code.

There are other SQL database engines with liberal licenses that allow the code to
be broadly and freely used. But those other engines are still governed by
copyright law. SQLite is different in that copyright law simply does not apply.

The source code files for other SQL database engines typically begin with a
comment describing your license rights to view and copy that file. The SQLite
source code contains no license since it is not governed by copyright. Instead of a
license, the SQLite source code offers a blessing:

May you do good and not evil

May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.

SQL language extensions

SQLite provides a number of enhancements to the SQL language not normally

found in other database engines. The EXPLAIN keyword and manifest typing have
already been mentioned above. SQLite also provides statements such as REPLACE
and the ON CONFLICT clause that allow for added control over the resolution of
constraint conflicts. SQLite supports ATTACH and DETACH commands that allow
multiple independent databases to be used together in the same query. And
SQLite defines APIs that allows the user to add new SQL functions and collating
sequences.
Datatypes In SQLite Version 3

Most SQL database engines (every SQL database engine other than SQLite, as far
as we know) uses static, rigid typing. With static typing, the datatype of a value
is determined by its container - the particular column in which the value is stored.

SQLite uses a more general dynamic type system. In SQLite, the datatype of a
value is associated with the value itself, not with its container. The dynamic type
system of SQLite is backwards compatible with the more common static type
systems of other database engines in the sense that SQL statement that work on
statically typed databases should work the same way in SQLite. However, the
dynamic typing in SQLite allows it to do things which are not possible in
traditional rigidly typed databases.
1.0 Storage Classes and Datatypes
Each value stored in an SQLite database (or manipulated by the database engine)
has one of the following storage classes:

• NULL. The value is a NULL value.

• INTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes
depending on the magnitude of the value.
• REAL. The value is a floating point value, stored as an 8-byte IEEE
floating point number.
• TEXT. The value is a text string, stored using the database encoding (UTF-
8, UTF-16BE or UTF-16LE).
• BLOB. The value is a blob of data, stored exactly as it was input.

Note that a storage class is slightly more general than a datatype. The INTEGER
storage class, for example, includes 6 different integer datatypes of different
lengths. This makes a difference on disk. But as soon as INTEGER values are read
off of disk and into memory for processing, they are converted to the most
general datatype (8-byte signed integer). And so for the most part, "storage
class" is indistinguishable from "datatype" and the two terms can be used
interchangeably.

Any column in an SQLite version 3 database, except an INTEGER PRIMARY KEY

column, may be used to store a value of any storage class.

All values in SQL statements, whether they are literals embedded in SQL
statement text or parameters bound to precompiled SQL statements have an
implicit storage class. Under circumstances described below, the database engine
may convert values between numeric storage classes (INTEGER and REAL) and
TEXT during query execution.
1.1 Boolean Datatype

SQLite does not have a separate Boolean storage class. Instead, Boolean values
are stored as integers 0 (false) and 1 (true).
1.2 Date and Time Datatype

SQLite does not have a storage class set aside for storing dates and/or times.
Instead, the built-in Date And Time Functions of SQLite are capable of storing
dates and times as TEXT, REAL, or INTEGER values:

• TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").

• REAL as Julian day numbers, the number of days since noon in Greenwich
on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
• INTEGER as Unix Time, the number of seconds since 1970-01-01
00:00:00 UTC.

Applications can chose to store dates and times in any of these formats and freely
convert between formats using the built-in date and time functions.
2.0 Type Affinity

In order to maximize compatibility between SQLite and other database engines,

SQLite supports the concept of "type affinity" on columns. The type affinity of a
column is the recommended type for data stored in that column. The important
idea here is that the type is recommended, not required. Any column can still
store any type of data. It is just that some columns, given the choice, will prefer
to use one storage class over another. The preferred storage class for a column is
called its "affinity".

Each column in an SQLite 3 database is assigned one of the following type

affinities:

• TEXT
• NUMERIC
• INTEGER
• REAL
• NONE

A column with TEXT affinity stores all data using storage classes NULL, TEXT or
BLOB. If numerical data is inserted into a column with TEXT affinity it is converted
into text form before being stored.

A column with NUMERIC affinity may contain values using all five storage classes.
When text data is inserted into a NUMERIC column, the storage class of the text
is converted to INTEGER or REAL (in order of preference) if such conversion is
lossless and reversible. For conversions between TEXT and REAL storage classes,
SQLite considers the conversion to be lossless and reversible if the first 15
significant decimal digits of the number are preserved. If the lossless conversion
of TEXT to INTEGER or REAL is not possible then the value is stored using the
TEXT storage class. No attempt is made to convert NULL or BLOB values.

A string might look like a floating-point literal with a decimal point and/or
exponent notation but as long as the value can be expressed as an integer, the
NUMERIC affinity will convert it into an integer. Hence, the string '3.0e+5' is
stored in a column with NUMERIC affinity as the integer 300000, not as the
floating point value 300000.0.

A column that uses INTEGER affinity behaves the same as a column with
NUMERIC affinity. The difference between INTEGER and NUMERIC affinity is only
evident in a CAST expression.

A column with REAL affinity behaves like a column with NUMERIC affinity except
that it forces integer values into floating point representation. (As an internal
optimization, small floating point values with no fractional component and stored
in columns with REAL affinity are written to disk as integers in order to take up
less space and are automatically converted back into floating point as the value is
read out. This optimization is completely invisible at the SQL level and can only
be detected by examining the raw bits of the database file.)

A column with affinity NONE does not prefer one storage class over another and
no attempt is made to coerce data from one storage class into another.
2.1 Determination Of Column Affinity

The affinity of a column is determined by the declared type of the column,

according to the following rules in the order shown:

1. If the declared type contains the string "INT" then it is assigned INTEGER
affinity.
2. If the declared type of the column contains any of the strings "CHAR",
"CLOB", or "TEXT" then that column has TEXT affinity. Notice that the type
VARCHAR contains the string "CHAR" and is thus assigned TEXT affinity.
3. If the declared type for a column contains the string "BLOB" or if no type
is specified then the column has affinity NONE.
4. If the declared type for a column contains any of the strings "REAL",
"FLOA", or "DOUB" then the column has REAL affinity.
5. Otherwise, the affinity is NUMERIC.

Note that the order of the rules for determining column affinity is important. A
column whose declared type is "CHARINT" will match both rules 1 and 2 but the
first rule takes precedence and so the column affinity will be INTEGER.
2.2 Affinity Name Examples

The following table shows how many common datatype names from more
traditional SQL implementations are converted into affinities by the five rules of
the previous section. This table shows only a small subset of the datatype names
that SQLite will accept. Note that numeric arguments in parentheses that
following the type name (ex: "VARCHAR(255)") are ignored by SQLite - SQLite
does not impose any length restrictions (other than the large global
SQLITE_MAX_LENGTH limit) on the length of strings, BLOBs or numeric values.

Example Typenames From

The Resulting Rule Used To Determine
CREATE TABLE Statement Affinity Affinity
or CAST Expression

INT INTEGER 1
INTEGER
TINYINT
SMALLINT
MEDIUMINT
BIGINT
 UNSIGNED BIG INT
INT2
INT8

CHARACTER(20)
VARCHAR(255)
VARYING CHARACTER(255)
NCHAR(55)
TEXT 2
NATIVE CHARACTER(70)
NVARCHAR(100)
TEXT
CLOB

BLOB
NONE 3
no datatype specified

REAL
DOUBLE
REAL 4
DOUBLE PRECISION
FLOAT

NUMERIC
DECIMAL(10,5)
BOOLEAN NUMERIC 5
DATE
DATETIME

Note that a declared type of "FLOATING POINT" would give INTEGER affinity, not
REAL affinity, due to the "INT" at the end of "POINT". And the declared type of
"STRING" has an affinity of NUMERIC, not TEXT.
2.3 Column Affinity Behavior Example

The following SQL demonstrates how SQLite uses column affinity to do type
conversions when values are inserted into a table.

CREATE TABLE t1(

t TEXT, -- text affinity by rule 2
nu NUMERIC, -- numeric affinity by rule 5
i INTEGER, -- integer affinity by rule 1
r REAL, -- real affinity by rule 4
no BLOB -- no affinity by rule 3
);

-- Values stored as TEXT, INTEGER, INTEGER, REAL, TEXT.

INSERT INTO t1 VALUES('500.0', '500.0', '500.0', '500.0', '500.0');
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
text|integer|integer|real|text

-- Values stored as TEXT, INTEGER, INTEGER, REAL, REAL.

DELETE FROM t1;
INSERT INTO t1 VALUES(500.0, 500.0, 500.0, 500.0, 500.0);
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
text|integer|integer|real|real

-- Values stored as TEXT, INTEGER, INTEGER, REAL, INTEGER.

DELETE FROM t1;
INSERT INTO t1 VALUES(500, 500, 500, 500, 500);
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
text|integer|integer|real|integer

-- BLOBs are always stored as BLOBs regardless of column affinity.

DELETE FROM t1;
INSERT INTO t1 VALUES(x'0500', x'0500', x'0500', x'0500', x'0500');
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
blob|blob|blob|blob|blob

-- NULLs are also unaffected by affinity

DELETE FROM t1;
INSERT INTO t1 VALUES(NULL,NULL,NULL,NULL,NULL);
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
null|null|null|null|null

3.0 Comparison Expressions

SQLite version 3 has the usual set of SQL comparison operators including "=",
"==", "<", "<=", ">", ">=", "!=", "<>", "IN", "NOT IN", "BETWEEN", "IS", and
"IS NOT", .
3.1 Sort Order

The results of a comparison depend on the storage classes of the operands,

according to the following rules:

• A value with storage class NULL is considered less than any other value
(including another value with storage class NULL).
• An INTEGER or REAL value is less than any TEXT or BLOB value. When an
INTEGER or REAL is compared to another INTEGER or REAL, a numerical
comparison is performed.
• A TEXT value is less than a BLOB value. When two TEXT values are
compared an appropriate collating sequence is used to determine the
result.
• When two BLOB values are compared, the result is determined using
memcmp().

3.2 Affinity Of Comparison Operands

SQLite may attempt to convert values between the storage classes INTEGER,
REAL, and/or TEXT before performing a comparison. Whether or not any
conversions are attempted before the comparison takes place depends on the
affinity of the operands. Operand affinity is determined by the following rules:

• An expression that is a simple reference to a column value has the same

affinity as the column. Note that if X and Y.Z are column names, then +X
 and +Y.Z are considered expressions for the purpose of determining
affinity.
• An expression of the form "CAST(expr AS type)" has an affinity that is the
same as a column with a declared type of "type".
• Otherwise, an expression has NONE affinity.

3.3 Type Conversions Prior To Comparison

To "apply affinity" means to convert an operand to a particular storage class if

and only if the conversion is lossless and reversible. Affinity is applied to
operands of a comparison operator prior to the comparison according to the
following rules in the order shown:

• If one operand has INTEGER, REAL or NUMERIC affinity and the other
operand as TEXT or NONE affinity then NUMERIC affinity is applied to
other operand.
• If one operand has TEXT affinity and the other has NONE affinity, then
TEXT affinity is applied to the other operand.
• Otherwise, no affinity is applied and both operands are compared as is.

The expression "a BETWEEN b AND c" is treated as two separate binary
comparisons "a >= b AND a <= c", even if that means different affinities are
applied to 'a' in each of the comparisons. Datatype conversions in comparisons of
the form "x IN (SELECT y ...)" are handled is if the comparison were really "x=y".
The expression "a IN (x, y, z, ...)" is equivalent to "a = +x OR a = +y OR a = +z
OR ...". In other words, the values to the right of the IN operator (the "x", "y",
and "z" values in this example) are considered to have no affinity, even if they
happen to be column values or CAST expressions.
3.4 Comparison Example

CREATE TABLE t1(

a TEXT, -- text affinity
b NUMERIC, -- numeric affinity
c BLOB, -- no affinity
d -- no affinity
);

-- Values will be stored as TEXT, INTEGER, TEXT, and INTEGER respectively

INSERT INTO t1 VALUES('500', '500', '500', 500);
SELECT typeof(a), typeof(b), typeof(c), typeof(d) FROM t1;
text|integer|text|integer

-- Because column "a" has text affinity, numeric values on the

-- right-hand side of the comparisons are converted to text before
-- the comparison occurs.
SELECT a < 40, a < 60, a < 600 FROM t1;
0|1|1
-- Text affinity is applied to the right-hand operands but since
-- they are already TEXT this is a no-op; no conversions occur.
SELECT a < '40', a < '60', a < '600' FROM t1;
0|1|1

-- Column "b" has numeric affinity and so numeric affinity is applied

-- to the operands on the right. Since the operands are already numeric,
-- the application of affinity is a no-op; no conversions occur. All
-- values are compared numerically.
SELECT b < 40, b < 60, b < 600 FROM t1;
0|0|1

-- Numeric affinity is applied to operands on the right, converting them

-- from text to integers. Then a numeric comparison occurs.
SELECT b < '40', b < '60', b < '600' FROM t1;
0|0|1

-- No affinity conversions occur. Right-hand side values all have

-- storage class INTEGER which are always less than the TEXT values
-- on the left.
SELECT c < 40, c < 60, c < 600 FROM t1;
0|0|0

-- No affinity conversions occur. Values are compared as TEXT.

SELECT c < '40', c < '60', c < '600' FROM t1;
0|1|1

-- No affinity conversions occur. Right-hand side values all have

-- storage class INTEGER which compare numerically with the INTEGER
-- values on the left.
SELECT d < 40, d < 60, d < 600 FROM t1;
0|0|1

-- No affinity conversions occur. INTEGER values on the left are

-- always less than TEXT values on the right.
SELECT d < '40', d < '60', d < '600' FROM t1;
1|1|1

All of the result in the example are the same if the comparisons are commuted -
if expressions of the form "a<40" are rewritten as "40>a".
4.0 Operators

All mathematical operators (+, -, *, /, %, <<, >>, &, and |) cast both operands
to the NUMERIC storage class prior to being carried out. The cast is carried
through even if it is lossy and irreversible. A NULL operand on a mathematical
operator yields a NULL result. An operand on a mathematical operator that does
not look in any way numeric and is not NULL is converted to 0 or 0.0.
5.0 Sorting, Grouping and Compound SELECTs
When query results are sorted by an ORDER BY clause, values with storage class
NULL come first, followed by INTEGER and REAL values interspersed in numeric
order, followed by TEXT values in collating sequence order, and finally BLOB
values in memcmp() order. No storage class conversions occur before the sort.

When grouping values with the GROUP BY clause values with different storage
classes are considered distinct, except for INTEGER and REAL values which are
considered equal if they are numerically equal. No affinities are applied to any
values as the result of a GROUP by clause.

The compound SELECT operators UNION, INTERSECT and EXCEPT perform

implicit comparisons between values. No affinity is applied to comparison
operands for the implicit comparisons associated with UNION, INTERSECT, or
EXCEPT - the values are compared as is.
6.0 Collating Sequences

When SQLite compares two strings, it uses a collating sequence or collating

function (two words for the same thing) to determine which string is greater or if
the two strings are equal. SQLite has three built-in collating functions: BINARY,
NOCASE, and RTRIM.

• BINARY - Compares string data using memcmp(), regardless of text

encoding.
• NOCASE - The same as binary, except the 26 upper case characters of
ASCII are folded to their lower case equivalents before the comparison is
performed. Note that only ASCII characters are case folded. SQLite does
not attempt to do full UTF case folding due to the size of the tables
required.
• RTRIM - The same as binary, except that trailing space characters are
ignored.

An application can register additional collating functions using the

sqlite3_create_collation() interface.
6.1 Assigning Collating Sequences from SQL

Every column of every table has an associated collating function. If no collating

function is explicitly defined, then the collating function defaults to BINARY. The
COLLATE clause of the column definition is used to define alternative collating
functions for a column.

The rules for determining which collating function to use for a binary comparison
operator (=, <, >, <=, >=, !=, IS, and IS NOT) are as follows and in the order
shown:
 1. If either operand has an explicit collating function assignment using the
postfix COLLATE operator, then the explicit collating function is used for
comparison, with precedence to the collating function of the left operand.
2. If either operand is a column, then the collating function of that column is
used with precedence to the left operand. For the purposes of the previous
sentence, a column name preceded by one or more unary "+" operators is
still considered a column name.
3. Otherwise, the BINARY collating function is used for comparison.

An operand of a comparison is considered to have an explicit collating function

assignment (rule 1 above) if any subexpression of the operand uses the postfix
COLLATE operator. Thus, if a COLLATE operator is used anywhere in a
comparision expression, the collating function defined by that operator is used for
string comparison regardless of what table columns might be a part of that
expression. If two or more COLLATE operator subexpressions appear anywhere in
a comparison, the left most explicit collating function is used regardless of how
deeply the COLLATE operators are nested in the expression and regardless of how
the expression is parenthesized.

The expression "x BETWEEN y and z" is logically equivalent to two comparisons "x
>= y AND x <= z" and works with respect to collating functions as if it were two
separate comparisons. The expression "x IN (SELECT y ...)" is handled in the
same way as the expression "x = y" for the purposes of determining the collating
sequence. The collating sequence used for expressions of the form "x IN (y,
z, ...)" is the collating sequence of x.

Terms of the ORDER BY clause that is part of a SELECT statement may be

assigned a collating sequence using the COLLATE operator, in which case the
specified collating function is used for sorting. Otherwise, if the expression sorted
by an ORDER BY clause is a column, then the collating sequence of the column is
used to determine sort order. If the expression is not a column and has no
COLLATE clause, then the BINARY collating sequence is used.
6.2 Collation Sequence Examples

The examples below identify the collating sequences that would be used to
determine the results of text comparisons that may be performed by various SQL
statements. Note that a text comparison may not be required, and no collating
sequence used, in the case of numeric, blob or NULL values.

CREATE TABLE t1(

x INTEGER PRIMARY KEY,
a, /* collating sequence BINARY */
b COLLATE BINARY, /* collating sequence BINARY */
c COLLATE RTRIM, /* collating sequence RTRIM */
 d COLLATE NOCASE /* collating sequence NOCASE */
);
/* x a b c d */
INSERT INTO t1 VALUES(1,'abc','abc', 'abc ','abc');
INSERT INTO t1 VALUES(2,'abc','abc', 'abc', 'ABC');
INSERT INTO t1 VALUES(3,'abc','abc', 'abc ', 'Abc');
INSERT INTO t1 VALUES(4,'abc','abc ','ABC', 'abc');

/* Text comparison a=b is performed using the BINARY collating sequence. */

SELECT x FROM t1 WHERE a = b ORDER BY x;
--result 1 2 3

/* Text comparison a=b is performed using the RTRIM collating sequence. */

SELECT x FROM t1 WHERE a = b COLLATE RTRIM ORDER BY x;
--result 1 2 3 4

/* Text comparison d=a is performed using the NOCASE collating sequence. */

SELECT x FROM t1 WHERE d = a ORDER BY x;
--result 1 2 3 4

/* Text comparison a=d is performed using the BINARY collating sequence. */

SELECT x FROM t1 WHERE a = d ORDER BY x;
--result 1 4

/* Text comparison 'abc'=c is performed using the RTRIM collating sequence. */

SELECT x FROM t1 WHERE 'abc' = c ORDER BY x;
--result 1 2 3

/* Text comparison c='abc' is performed using the RTRIM collating sequence. */

SELECT x FROM t1 WHERE c = 'abc' ORDER BY x;
--result 1 2 3

/* Grouping is performed using the NOCASE collating sequence (Values

** 'abc', 'ABC', and 'Abc' are placed in the same group). */
SELECT count(*) FROM t1 GROUP BY d ORDER BY 1;
--result 4

/* Grouping is performed using the BINARY collating sequence. 'abc' and

** 'ABC' and 'Abc' form different groups */
SELECT count(*) FROM t1 GROUP BY (d || '') ORDER BY 1;
--result 1 1 2

/* Sorting or column c is performed using the RTRIM collating sequence. */

SELECT x FROM t1 ORDER BY c, x;
--result 4 1 2 3

/* Sorting of (c||'') is performed using the BINARY collating sequence. */

SELECT x FROM t1 ORDER BY (c||''), x;
--result 4 2 3 1
/* Sorting of column c is performed using the NOCASE collating sequence. */
SELECT x FROM t1 ORDER BY c COLLATE NOCASE, x;
--result 2 4 3 1

SQL Features That SQLite Does Not Implement

Rather than try to list all the features of SQL92 that SQLite does support, it is
much easier to list those that it does not. Unsupported features of SQL92 are
shown below.

The order of this list gives some hint as to when a feature might be added to
SQLite. Those features near the top of the list are likely to be added in the near
future. There are no immediate plans to add features near the bottom of the list.

RIGHT and LEFT OUTER JOIN is implemented, but not RIGHT OUTER
FULL OUTER JOIN or FULL OUTER JOIN.
JOIN

Complete Only the RENAME TABLE and ADD COLUMN variants of the
ALTER TABLE ALTER TABLE command are supported. Other kinds of ALTER
support TABLE operations such as DROP COLUMN, ALTER COLUMN,
ADD CONSTRAINT, and so forth are omitted.

Complete FOR EACH ROW triggers are supported but not FOR EACH
trigger STATEMENT triggers.
support

Writing to VIEWs in SQLite are read-only. You may not execute a

VIEWs DELETE, INSERT, or UPDATE statement on a view. But you
can create a trigger that fires on an attempt to DELETE,
INSERT, or UPDATE a view and do what you need in the
body of the trigger.

GRANT and Since SQLite reads and writes an ordinary disk file, the only
REVOKE access permissions that can be applied are the normal file
access permissions of the underlying operating system. The
GRANT and REVOKE commands commonly found on
client/server RDBMSes are not implemented because they
would be meaningless for an embedded database engine.

If you find other SQL92 features that SQLite does not support, please add them
to the Wiki page at http://www.sqlite.org/cvstrac/wiki?p=UnsupportedSql

SQLite Limitations

SQLite is different from most other modern SQL databases in that its primary
design goal is to be simple. SQLite follows this goal, even if it leads to occasional
inefficient implementations of some features. The following is a list of
shortcomings of SQLite:

SQL-92 feature

As mentioned previously, SQLite does not support some SQL-92 features

that are available in many enterprise database systems. You can obtain
the latest information from the SQLite homepage.

Low concurrency

SQLite supports only flat transactions; it does not have nesting and
savepoint capabilities. (Nesting means the capability of having
subtransactions in a transaction. Savepoints allow a transaction to revert
back to previously established states.) It is not capable of ensuring a high
degree of transaction concurrency. It permits many concurrent read-
transactions, but only one exclusive write-transaction on a single database
file. This limitation means that if any transaction is reading from any part
of a database file, all other transactions are prevented from writing any
part of the file. Similarly, if any one transaction is writing to any part of a
database file, all other transactions are prevented from reading or writing
any part of the file.

Application restriction

Because of its limited transactional concurrency, SQLite is only good for

small-size transactions. In many situations, this is not a problem. Each
application does its database work quickly and moves on, and hence no
database is held up by a transaction for more than a few milliseconds. But
there are some applications, especially write-intensive ones, that require
more transactional concurrency (table or row level instead of database
level), and you should use a different DBMS for such applications. SQLite
is not intended to be an enterprise DBMS. It is optimal in situations where
simplicity of database implementation, maintenance, and administration
are more important than the countless complex features that enterprise
DBMSs provide.

NFS problems
 SQLite uses native file locking primitives to control transaction
concurrency. This may cause some problems if database files reside on
network partitions. Many NFS implementations are known to contain bugs
(on Unix and Windows) in their file locking logic. If file locking does not
work the way it is expected, it might be possible for two or more
applications to modify the same part of the same database at the same
time, resulting in a database corruption. Because this problem arises due
to bugs in the underlying filesystem implementation, there is nothing
SQLite can do to prevent it.

Another thing is that because of the latency associated with most network
filesystems, performance may not be good. In such environments, in
cases where the database files must be accessed across the network, a
DBMS that implements a client-server model might be more effective than
SQLite.

Database size

Because of its developers' engineering design choices, SQLite may not be

a good choice for very large databases. In theory, a database file can be
as large as two terabytes (241) long. The logging subsystem has memory
overhead that is proportional to the database size. For every write
transaction, SQLite maintains one bit of in-memory information for every
database page, whether the transaction even reads or writes that page.
(The default page size is 1024 bytes.) Thus, memory overhead may
become a severe bottleneck for databases that have more than a few
million pages.

Number and type of objects

A table or index is limited by at most 264 – 1 entries. (Of course, you
cannot have this many entries because of the 241 bytes database size
limit.) A single entry can hold up to 230 bytes of data in SQLite's current
implementation. (The underlying file format supports row sizes up to
about 262 bytes of data.) Upon opening a database file, SQLite reads and
preprocesses all entries from the master catalog table and creates many
in-memory catalog objects. So, for best performance, it is better to keep
down the number of tables, indexes, views, and triggers. Likewise, though
there is no limit on the number of columns in a table, more than a few
hundred seems extreme. Only the first 31 columns of a table are
 candidates for certain optimizations. You can put as many columns in an
index as you like, but indexes with more than 30 columns will not be used
to optimize queries.

Host variable reference

In some embedded DBMSs, SQL statements can reference host variables

(i.e., those from application space) directly. This is not possible in SQLite.
SQLite instead permits binding of host variables to SQL statements using
sqlite3_bind_* API functions for input parameters, and not for output
values. This approach is generally better than the direct access approach
because the latter requires a special preprocessor that converts SQL
statements into special API calls.

Stored procedure

Many DBMSs have capability to create and store what are called stored
procedures. A stored procedure is a group of SQL statements that form a
logical unit of work and perform a particular task. SQL queries can use
these procedures. SQLite does not have this capability.

PostgreSQL

PostgreSQL

PostgreSQL Global
Developer(s)
Development Group
 9.0.1 /
8.4.5 /
8.3.12 /
8.2.18 /
Stable release
8.1.22 /
8.0.26 /
7.4.30 /
October 4, 2010; 57 days ago
9.1alpha1 / September 7,
Preview release
2010; 2 months ago
Written in C
Operating system Cross-platform
Type ORDBMS
License PostgreSQL licence[1][2][3]
Website http://www.postgresql.org/

PostgreSQL, often simply Postgres, is an object-relational database

management system (ORDBMS).[4] It is released under an MIT-style license and is
thus free and open source software. As with many other open-source programs,
PostgreSQL is not controlled by any single company — a global community of
developers and companies develops the system.

[edit] Product name

The mixed-capitalization of the PostgreSQL name can confuse some people on

first viewing. The several pronunciations of "SQL" can lead to this confusion.
PostgreSQL's developers pronounce it /ˈpoʊstɡrɛs ˌkjuː ˈɛl/; (Audio sample, 5.6k
MP3). It is abbreviated as "Postgres", its original name. Because of ubiquitous
support for the SQL Standard amongst most relational databases, the community
considered changing the name back to Postgres. However, the PostgreSQL Core
Team announced in 2007 that the product would continue to use the name
PostgreSQL.[5] The name refers to the project's origins as a "post-Ingres"
database, the original authors having also developed the Ingres database. (The
name Ingres was an abbreviation for INteractive Graphics REtrieval System.)

[edit] History

PostgreSQL evolved from the Ingres project at the University of California,

Berkeley. In 1982, the project leader, Michael Stonebraker, left Berkeley to make
a proprietary version of Ingres. He returned to Berkeley in 1985 and started a
post-Ingres project to address the problems with contemporary database systems
that had become increasingly clear during the early 1980s. The new project,
Postgres, aimed to add the fewest features needed to completely support types.
These features included the ability to define types and to fully describe
relationships – something used widely before but maintained entirely by the user.
In Postgres, the database "understood" relationships, and could retrieve
information in related tables in a natural way using rules. Postgres used many of
the ideas of Ingres, but not its code.

Starting in 1986, the team published a number of papers describing the basis of
the system, and by 1988 had a prototype version. The team released version 1 to
a small number of users in June 1989, then version 2 with a re-written rules
system in June 1990. Version 3, released in 1991, again re-wrote the rules
system, and added support for multiple storage managers and an improved query
engine. By 1993 the great number of users began to overwhelm the project with
requests for support and features. After releasing version 4 — primarily a
cleanup — the project ended.

But open-source developers could obtain copies and develop the system further,
because Berkeley had released Postgres under a MIT-style license. In 1994,
Berkeley graduate students Andrew Yu and Jolly Chen replaced the Ingres-based
QUEL query language interpreter with one for the SQL query language, creating
Postgres95. The code was released on the web.

In July 1996, Marc Fournier at Hub.Org Networking Services provided the first
non-university development server for the open-source development effort. Along
with Bruce Momjian and Vadim B. Mikheev, work began to stabilize the code
inherited from Berkeley. The first open-source version was released on August 1,
1996.

In 1996, the project was renamed to PostgreSQL to reflect its support for SQL.
The first PostgreSQL release formed version 6.0 in January 1997. Since then, the
software has been maintained by a group of database developers and volunteers
around the world, coordinating via the Internet.

The PostgreSQL project continues to make major releases (approximately

annually) and minor "bugfix" releases, all available under the same license. Code
comes from contributions from proprietary vendors, support companies, and
open-source programmers at large.

[edit] Major releases

Release First date Latest Latest date Additions

minor
 version

0.01 1995-05-01 0.03 1995-07-21 Initial release as Postgres95

Changed copyright to a more liberal

1.0 1995-09-05 1.09 1996-11-04
license

Name change from Postgres95 to

6.0 1997-01-29 —
PostgreSQL

6.1 1997-06-08 6.1.1 1997-07-22

6.2 1997-10-02 6.2.1 1997-10-17

SQL92 subselect capability,

6.3 1998-03-01 6.3.2 1998-04-07
PL/pgTCL

6.4 1998-10-30 6.4.2 1998-12-20 VIEWs and RULEs, PL/pgSQL

MVCC, temporary tables, more SQL

6.5 1999-06-09 6.5.3 1999-10-13 statement support (CASE,
INTERSECT, and EXCEPT)

7.0 2000-05-08 7.0.3 2000-11-11 Foreign keys, Inner joins

7.1 2001-04-13 7.1.3 2001-08-15 Write-ahead Log, Outer joins

7.2 2002-02-04 7.2.8 2005-05-09 PL/Python

7.3 2002-11-27 7.3.21 2008-01-07 Schema, Internationalization

7.4 2003-11-17 7.4.30 2010-10-04 Optimization all-round

8.0 2005-01-19 8.0.26 2010-10-04 Native server on Microsoft Windows,

savepoints, tablespaces, exception
handling in functions, point-in-time
 recovery

Performance optimization, two-

phase commit, table partitioning,
8.1 2005-11-08 8.1.22 2010-10-04
index bitmap scan, shared row
locking, roles

Performance optimization, online

8.2 2006-12-05 8.2.18 2010-10-04 index builds, advisory locks, warm
standby

Full text search, SQL/XML, ENUM

8.3 2008-02-04 8.3.12 2010-10-04
types, UUID types

Windowing functions, default and

variadic parameters for functions,
column-level permissions, parallel
8.4 2009-07-01 8.4.5 2010-10-04
database restore, per-database
collation, common table expressions
and recursive queries

Built-in binary streaming replication,

Hot standby, 64-bit Windows, per-
column triggers and conditional
9.0 2010-09-20 9.0.1 2010-10-04
trigger execution, exclusion
constraints, anonymous code blocks,
named parameters, password rules

Community supported

Community support recently ended[6]

[edit] Features

[edit] Procedural languages

Procedural languages (often called stored procedures) allow blocks of code to be

executed by the database server, and can be written in programming languages
other than SQL and C. Procedural languages can be used to create user-defined
functions (subroutine, trigger, aggregates and window functions), and can also be
used in ad hoc "DO" blocks. The following four procedural languages are provided
by a standard PostgreSQL installation:
  PL/pgSQL, a built-in language that resembles Oracle's PL/SQL procedural
language
 PL/Tcl, provides Tcl
 PL/Perl, provides Perl
 PL/Python, provides Python, either version 2 or 3

Other non-standard procedural languages that have been developed outside the
core distribution includes (but is not limited to): PL/Lua (Lua), PL/php (PHP),
PL/Ruby (Ruby), PL/sh (any Unix-like shell), PL/scheme (Scheme), PL/Java
(Java), PL/R (R) and even PL/LOLCODE.

[edit] Indexes

PostgreSQL includes built-in support for B+-tree, hash, GiST and GiN indexes. In
addition, user-defined index methods can be created, although this is quite an
involved process. Indexes in PostgreSQL also support the following features:

 Expression indexes can be created with an index of the result of an

expression or function, instead of simply the value of a column.
 Partial indexes, which only index part of a table, can be created by
adding a WHERE clause to the end of the CREATE INDEX statement. This
allows a smaller index to be created.
 The planner is capable of using multiple indexes together to satisfy
complex queries, using temporary in-memory bitmap index operations.

[edit] Triggers

Triggers are events triggered by the action of SQL DML statements. For example,
an INSERT statement might activate a trigger that checked if the values of the
statement were valid. Most triggers are only activated by either INSERT or
UPDATE statements.

Triggers are fully supported and can be attached to tables but not to views. Views
can have rules, though. Multiple triggers are fired in alphabetical order. In
addition to calling functions written in the native PL/PgSQL, triggers can also
invoke functions written in other languages like PL/Perl.

[edit] MVCC

PostgreSQL manages concurrency through a system known as Multi-Version

Concurrency Control (MVCC), which gives each user a "snapshot" of the
database, allowing changes to be made without being visible to other users until
a transaction is committed. This largely eliminates the need for read locks, and
ensures the database maintains the ACID (atomicity, consistency, isolation,
durability) principles in an efficient manner.

[edit] Rules

Rules allow the "query tree" of an incoming query to be rewritten. One common
usage is to implement views, including updatable views. Rules, or more properly,
"Query Re-Write Rules", are attached to a table/class and "Re-Write" the
incoming DML (select, insert, update, and/or delete) into one or more queries
that either replace the original DML statement or execute in addition to it. Query
Re-Write occurs after DML statement parsing, but, before query planning.

[edit] Data types

A wide variety of native data types are supported, including:

 Variable length arrays (including text and composite types) up to 1GB in

total storage size.
 Arbitrary precision numerics
 Geometric primitives
 IPv4 and IPv6 addresses
 CIDR blocks and MAC addresses
 XML supporting Xpath queries (as of 8.3)
 UUID (as of 8.3)

In addition, users can create their own data types which can usually be made
fully indexable via PostgreSQL's GiST infrastructure. Examples of these include
the geographic information system (GIS) data types from the PostGIS project for
PostgreSQL.

[edit] User-defined objects

New types of almost all objects inside the database can be created, including:

 Casts
 Conversions
 Data types
 Domains
 Functions, including aggregate functions
 Indexes
 Operators (existing ones can be overloaded)
 Procedural languages
[edit] Inheritance

Tables can be set to inherit their characteristics from a "parent" table. Data in
child tables will appear to exist in the parent tables, unless data is selected from
the parent table using the ONLY keyword, i.e. select * from ONLY
PARENT_TABLE. Adding a column in the parent table will cause that column to
appear in the child table.

Inheritance can be used to implement table partitioning, using either triggers or

rules to direct inserts to the parent table into the proper child tables.

As of 2010 this feature is not fully supported yet—in particular, table constraints
are not currently inheritable. As of the 8.4 release, all check constraints and not-
null constraints on a parent table are automatically inherited by its children.
Other types of constraints (unique, primary key, and foreign key constraints) are
not inherited.

Inheritance provides a way to map the features of generalization hierarchies

depicted in Entity Relationship Diagrams (ERD) directly into the PostgreSQL
database.

[edit] Other features

 Referential integrity constraints including foreign key constraints, column

constraints, and row checks
 Views. Although views are by default not update-able, they can be made
so by creating "insert", "update", and/or "delete" Query Re-Write Rules on the
view.
 Inner, outer (full, left and right), and cross joins
 Sub-selects
[7]
 Correlated sub-queries
 Transactions
[8]
 Supports most of the major features of SQL:2008 standard
 Encrypted connections via SSL
 Binary and textual large-object storage
 Online backup
 Domains
 Tablespaces
 Savepoints
 Point-in-time recovery, implemented using Write-ahead logging
 Two-phase commit
  TOAST (The Oversized-Attribute Storage Technique) is used to
transparently store large table attributes (such as big MIME attachments or
XML messages) in a separate area, with automatic compression.
[9]
 Regular expressions
 Common table expressions
 Embedded SQL is implemented using preprocessor. SQL code is first
written embedded into C code. Then code is run through ECPG preprocessor,
which replaces SQL with calls to code library. Then code can be compiled
using C compiler. Embedding works also with C++ but it does not recognize
all C++ constructs.
 Full text search

[edit] Replication

PostgreSQL 9.0 includes built-in binary replication, based on shipping the changes
(write-ahead logs) to slave systems asynchronously. Adding synchronous
replication is on the roadmap for the 9.1 release.

Version 9.0 also introduces the ability to run read-only queries against these
replicated slaves, where earlier versions would only allow that after promoting
them to be a new master. This allows splitting read traffic among multiple nodes
efficiently. Earlier replication software that allowed similar read scaling normally
relied on adding replication triggers to the master, introducing additional load
onto it.

There are also several asynchronous trigger-based replication packages for

PostgreSQL. These remain useful even after introduction of the expanded core
capabilities, for situations where binary replication of an entire database cluster
isn't the appropriate approach:

 Slony-I
 Londiste (part of SkyTools by Skype)
 Mammoth Replicator (by Command Prompt. Formerly proprietary, now
open source)[10]
 Bucardo (Multi-master replication, developed as part of Backcountry.com)
[11]

There are also proxy (middleware) tools that enable replication, failover or load
management and balancing for PostgreSQL:

 PGPool-II
  Continuent Sequoia, also available for other database software

[edit] Add-ons

 Performance wizard - included with any Postgres download from

EnterpriseDB. Source code also available.
 MySQL migration wizard - included with any Postgres download from
EnterpriseDB. Source code also available.
 Geographic objects via PostGIS. GPL.
 Shortest-Path-Algorithms with pgRouting using PostGIS. GPL.

[edit] Database administration front-ends

[edit] Open source

[edit] psql

The primary front-end for PostgreSQL is the psql command-line program, which
can be used to enter SQL queries directly, or execute them from a file. In
addition, psql provides a number of meta-commands and various shell-like
features to facilitate writing scripts and automating a wide variety of tasks; for
example tab completion of object names and SQL syntax.

[edit] pgAdmin

pgAdmin is a free and open source graphical front-end administration tool for
PostgreSQL, which is supported on most popular computer platforms. The
program is available in more than a dozen languages. The first prototype, named
pgManager, was written for PostgreSQL 6.3.2 from 1998, and rewritten and
released as pgAdmin under the GPL License in later months. The second
incarnation (named pgAdmin II) was a complete rewrite, first released on 16
January 2002. The current version is pgAdmin III, which was originally released
under the Artistic License and is now released under the same license as
PostgreSQL. Unlike prior versions that were written in Visual Basic, pgAdmin III is
written in C++, using the wxWidgets framework allowing it to run on most
common operating systems.

[edit] phpPgAdmin

phpPgAdmin is a web-based administration tool for PostgreSQL written in PHP

and based on the popular phpMyAdmin interface originally written for MySQL
administration.[12]

[edit] Proprietary
A number of companies offer proprietary tools for PostgreSQL. They often consist
of a universal core that is adapted for various specific database products. These
tools mostly share the administration features with the open source tools but
offer improvements in data modeling, importing, exporting or reporting.

See also: Comparison of database tools

[edit] Benchmarks and Performance

Many informal performance studies of PostgreSQL have been done[13].

Performance improvements aimed at improving scalability started heavily
with version 8.1, and running simple benchmarks version 8.4 has been
shown to be more than 10 times faster on read only workloads and at least
7.5 times faster on both read and write workloads compared with version
8.0.[14]

The first industry-standard and peer-validated benchmark was completed in

June 2007 using the Sun Java System Application Server (proprietary
version of GlassFish) 9.0 Platform Edition, UltraSPARC T1 based Sun Fire
server and Postgres 8.2.[15] This result of 778.14 SPECjAppServer2004
JOPS@Standard compares favourably with the 874 JOPS@Standard with
Oracle 10 on an Itanium based HP-UX system.[13]

In August 2007, Sun submitted an improved benchmark score of 813.73

SPECjAppServer2004 JOPS@Standard. With the system under test at a
reduced price, the price/performance improved from $US 84.98/JOPS to $US
70.57/JOPS.[16]

The default configuration of PostgreSQL only uses a small amount of

dedicated memory for performance critical purposes such as caching
database blocks and sorting. This limitation is primarily because many
operating systems will not allow allocating large blocks of shared memory by
default, which means the database requires runtime kernel changes before it
can be tuned properly. Advice on basic recommended performance practice
covering all recent versions of PostgreSQL is available at Tuning Your
PostgreSQL Server.

[edit] Prominent users

 Yahoo! for web user behavioral analysis, storing two petabytes and
claimed to be the largest data warehouse using a heavily modified
version of PostgreSQL with an entirely different column-based storage
engine and different query processing layer. While for performance,
 storage, and query purposes the database bears little resemblance to
PostgreSQL, the front-end maintains compatibility so that Yahoo can use
many off-the-shelf tools already written to interact with PostgreSQL.[17][18]
 MySpace, a popular social networking website, is using Aster
nCluster Database for data warehousing, which is built on unmodified
PostgreSQL.[19][20]
 OpenStreetMap, a collaborative project to create a free editable
map of the world.[21]
 Afilias, domain registries for .org, .info and others.[22]
 Sony Online multiplayer online games.[23]
 BASF, shopping platform for their agribusiness portal.[24]
 hi5.com social networking portal.[25]
 reddit.com social news website.[26]
 Skype VoIP application, central business databases.[27]
 Sun xVM, Sun's virtualization and datacenter automation suite.[28]
 Evergreen, an open source integrated library system providing an
Online Public Access Catalog and cataloging, management, and other
functions for hundreds of libraries in the United States, Canada, and
elsewhere.
 MusicBrainz, open online music encyclopedia.
 International Space Station for collecting telemetry data in orbit
and replicating to the ground.[29]
 MyYearbook social networking site[30]

[edit] Awards

As of 2008 PostgreSQL has received the following awards:[31]

 1999 LinuxWorld Editor's Choice Award for Best Database

 2000 Linux Journal Editors' Choice Awards for Best Database
 2002 Linux New Media Editors Choice Award for Best Database
 2003 Linux Journal Editors' Choice Awards for Best Database
 2004 Linux New Media Award For Best Database
 2004 Linux Journal Editors' Choice Awards for Best Database
 2004 ArsTechnica Best Server Application Award
 2005 Linux Journal Editors' Choice Awards for Best Database
 2006 Linux Journal Editors' Choice Awards for Best Database
 2008 Developer.com Product of the Year, Database Tool
[edit] Proprietary derivatives and support

Although the license allowed proprietary products based on Postgres, the

code did not develop in the proprietary space at first. The main offshoot
originated when Paula Hawthorn (an original Ingres team member who
moved from Ingres) and Michael Stonebraker formed Illustra Information
Technologies to make a proprietary product based on Postgres.

In 2000, former Red Hat investors created the company Great Bridge to
make a proprietary product based on PostgreSQL and compete against
proprietary database vendors. Great Bridge sponsored several PostgreSQL
developers and donated many resources back to the community,[32] but by
late 2001 closed due to tough competition from companies like Red Hat and
to poor market conditions.[33]

In 2001, Command Prompt, Inc. released Mammoth PostgreSQL, a

proprietary product based on PostgreSQL. In 2008, Command Prompt, Inc.
released the source under the original license. Command Prompt, Inc.
continues to support the PostgreSQL community actively through developer
sponsorships and projects including PL/Perl, PL/php, and hosting of
community projects such as the PostgreSQL Build Farm.

In January 2005, PostgreSQL received backing by database vendor Pervasive

Software, known for its Btrieve product which was ubiquitous on the Novell
NetWare platform. Pervasive announced commercial support and community
participation and achieved some success. In July 2006, Pervasive left the
PostgreSQL support market.[34]

In mid-2005 two other companies announced plans to make proprietary

products based on PostgreSQL with focus on separate niche markets.
EnterpriseDB added functionality to allow applications written to work with
Oracle to be more readily run with PostgreSQL. Greenplum contributed
enhancements directed at data warehouse and business intelligence
applications, including the BizGres project.

In October 2005, John Loiacono, executive vice president of software at Sun

Microsystems, commented: "We're not going to OEM Microsoft but we are
looking at PostgreSQL right now,"[35] although no specifics were released at
that time. By November 2005, Sun had announced support for PostgreSQL.
[36]
By June 2006, Sun Solaris 10 (6/06 release) shipped with PostgreSQL.

In August 2007, EnterpriseDB announced[37] the Postgres Resource Center

[1] and EnterpriseDB Postgres, designed as a fully configured distribution of
PostgreSQL including many contrib modules and add-on components.
EnterpriseDB Postgres was renamed to Postgres Plus in March 2008.
Postgres Plus is available in two versions: Postgres Plus Standard Server
which has all the features of PostgreSQL plus additional QA testing,
integrated components, tuning and one-click install, and Postgres Plus
Advanced Server which has all the features of Postgres Standard Server plus
Oracle compatibility, scalability features, and DBA and developer tools. Both
versions are available for free and are fully supported, though the free
version of Postgres Plus Advanced Server is restricted by a "limited use"
license, which is defined as "confined to a single CPU, utilizing 1 GB RAM,
storing no more than 6GB of data in a NON-PRODUCTION environment."