SQLiteDeveloper(s) D. Richard HippInitial release August 2000

Stable release3.7.3 / October 8, 2010; 53 days ago

Written in COperating system Cross-platformSize ~275 kiBType 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

CREATE TABLE Statementor CAST Expression

Resulting Affinity

Rule Used To Determine Affinity

INTINTEGERTINYINT

SMALLINTMEDIUMINT

BIGINTUNSIGNED BIG INT

INT2INT8

INTEGER 1

CHARACTER(20)VARCHAR(255)

VARYING CHARACTER(255)NCHAR(55)

NATIVE CHARACTER(70)NVARCHAR(100)

TEXTCLOB

TEXT 2

BLOBno datatype specified NONE 3

REALDOUBLE

DOUBLE PRECISIONFLOAT

REAL 4

NUMERICDECIMAL(10,5)

BOOLEANDATE

DATETIME

NUMERIC 5

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 affinityDELETE 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 respectivelyINSERT 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 FULL OUTER JOIN

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

Complete ALTER TABLE support  

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

Complete trigger support

 FOR EACH ROW triggers are supported but not FOR EACH STATEMENT triggers.

Writing to VIEWs

 

VIEWs in SQLite are read-only. You may not execute a 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 REVOKE

 

Since SQLite reads and writes an ordinary disk file, the only 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

Developer(s)PostgreSQL Global Development Group

Stable release 9.0.1 /8.4.5 /8.3.12 /8.2.18 /8.1.22 /8.0.26 /

7.4.30 /October 4, 2010; 57 days ago

Preview release9.1alpha1 / September 7, 2010; 2 months ago

Written in COperating system Cross-platformType ORDBMSLicense 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 minor

versionLatest date Additions

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

1.0 1995-09-05 1.09 1996-11-04 Changed copyright to a more liberal

license

6.0 1997-01-29 — Name change from Postgres95 to PostgreSQL

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

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

6.3 1998-03-01 6.3.2 1998-04-07 SQL92 subselect capability, PL/pgTCL

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

6.5 1999-06-09 6.5.3 1999-10-13MVCC, temporary tables, more SQL 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-04Native server on Microsoft Windows, savepoints, tablespaces, exception handling in functions, point-in-time recovery

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

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

8.3 2008-02-04 8.3.12 2010-10-04 Full text search, SQL/XML, ENUM types, UUID types

8.4 2009-07-01 8.4.5 2010-10-04

Windowing functions, default and variadic parameters for functions, column-level permissions, parallel database restore, per-database collation, common table expressions and recursive queries

9.0 2010-09-20 9.0.1 2010-10-04

Built-in binary streaming replication, Hot standby, 64-bit Windows, per-column triggers and conditional 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

← Correlated sub-queries [7] ← Transactions ← Supports most of the major features of SQL:2008 standard [8] ← 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.

← Regular expressions [9] ← 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."