Comparison of relational database management systems

The following tables compare general and technical information for a number of relational database management systems. Please see the individual products' articles for further information. Unless otherwise specified in footnotes, comparisons are based on the stable versions without any add-ons, extensions or external programs.

Operating system support
The operating systems that the RDBMSes can run on.

Fundamental features
Information about what fundamental RDBMS features are implemented natively.


 * Note (1): Currently only supports read uncommitted transaction isolation. Version 1.9 adds serializable isolation and version 2.0 will be fully ACID compliant.
 * Note (2): MariaDB and MySQL provide ACID compliance through the default InnoDB storage engine.
 * Note (3): "For other than InnoDB storage engines, MySQL Server parses and ignores the FOREIGN KEY and REFERENCES syntax in CREATE TABLE statements. The CHECK clause is parsed but ignored by all storage engines."
 * Note (4): Support for Unicode is new in version 10.0.
 * Note (5): MySQL provides GUI interface through MySQL Workbench.
 * Note (6): OpenEdge SQL database engine uses Referential Integrity, OpenEdge ABL Database engine does not and is handled via database triggers.

Limits
Information about data size limits.
 * Note (1): Firebird 2.x maximum database size is effectively unlimited with the largest known database size >980 GB. Firebird 1.5.x maximum database size: 32 TB.
 * Note (2): Limit is 1038 using  datatype.
 * Note (3): InnoDB is limited to 8,000 bytes (excluding,  ,  , or   columns).
 * Note (4): InnoDB is limited to 1,017 columns.
 * Note (6): Using  in SQL 2005 and later.
 * Note (7): When using a page size of 32 KB, and when BLOB/CLOB data is stored in the database file.
 * Note (8): Java array size limit of 2,147,483,648 (231) objects per array applies. This limit applies to number of characters in names, rows per table, columns per table, and characters per  /.
 * Note (9): Despite the lack of a date datatype, SQLite does include date and time functions, which work for timestamps between 24 November 4714 B.C. and 1 November 5352.
 * Note (10): Informix DATETIME type has adjustable range from YEAR only through 1/10000th second. DATETIME date range is 0001-01-01 00:00:00.00000 through 9999-12-31 23:59:59.99999.
 * Note (11): Since version 12c. Earlier versions support up to $65,530 B$.
 * <cite id="limit_12">Note (12): The $2 ZB$ limit refers to the storage limit of a single Informix server instance. Informix v12.10 and later versions support using sharding techniques to distribute a table across multiple server instances. A distributed Informix database has no upper limit on table or database size.
 * <cite id="limit_13">Note (13): Informix DECIMAL type supports up to 32 decimal digits of precision with a range of to . Fixed and variable precision are supported.

Tables and views
Information about what tables and views (other than basic ones) are supported natively.


 * <cite id="tb_1">Note (1): Server provides tempdb, which can be used for public and private (for the session) temp tables.
 * <cite id="tb_2">Note (2): Materialized views are not supported in Informix; the term is used in IBM's documentation to refer to a temporary table created to run the view's query when it is too complex, but one cannot for example define the way it is refreshed or build an index on it. The term is defined in the Informix Performance Guide.
 * <cite id="tb_4">Note (4): Materialized views can be emulated using stored procedures and triggers.

Indexes
Information about what indexes (other than basic B-/B+ tree indexes) are supported natively.


 * <cite id="idx_1">Note (1): The users need to use a function from freeAdhocUDF library or similar.
 * <cite id="idx_2">Note (2): Can be implemented for most data types using expression-based indexes.
 * <cite id="idx_3">Note (3): Can be emulated by indexing a computed column (doesn't easily update) or by using an "Indexed View" (proper name not just any view works ).
 * <cite id="idx_4">Note (4): Used for InMemory ColumnStore index, temporary hash index for hash join, Non/Cluster & fill factor.
 * <cite id="idx_5">Note (5): InnoDB automatically generates adaptive hash index entries as needed.
 * <cite id="idx_6">Note (6): Can be implemented using Function-based Indexes in Oracle 8i and higher, but the function needs to be used in the sql for the index to be used.
 * <cite id="idx_7">Note (7): A PostgreSQL functional index can be used to reverse the order of a field.
 * <cite id="idx_10">Note (10): B+ tree and full-text only for now.
 * <cite id="idx_11">Note (11): R-Tree indexing available in base edition with Locator but some functionality requires Personal Edition or Enterprise Edition with Spatial option.

Database capabilities

 * <cite id="capa_1">Note (1): Recursive CTEs introduced in 11gR2 supersedes similar construct called CONNECT BY.

Other objects
Information about what other objects are supported natively.


 * <cite id="other_1">Note (1): Both function and procedure refer to internal routines written in SQL and/or procedural language like PL/SQL. External routine refers to the one written in the host languages, such as C, Java, Cobol, etc. "Stored procedure" is a commonly used term for these routine types. However, its definition varies between different database vendors.
 * <cite id="other_2">Note (2): In Derby, H2, LucidDB, and CUBRID, users code functions and procedures in Java.
 * <cite id="other_3">Note (3): ENUM datatype exists. CHECK clause is parsed, but not enforced in runtime.
 * <cite id="other_5">Note (5): Informix supports external functions written in Java, C, & C++.

Partitioning
Information about what partitioning methods are supported natively.

Access control
Information about access control functionalities.


 * <cite id="ac_1">Note (1): Network traffic could be transmitted in a secure way (not clear-text, in general SSL encryption). Precise if option is default, included option or an extra modules to buy.
 * <cite id="ac_2">Note (2): Options are present to set a minimum size for password, respect complexity like presence of numbers or special characters.
 * <cite id="ac_3">Note (3): How do you get security updates? Is it free access, do you need a login or to pay? Is there easy access through a Web/FTP portal or RSS feed or only through offline access (mail CD-ROM, phone).
 * <cite id="ac_4">Note (4): Does database process run as root/administrator or unprivileged user? What is default configuration?
 * <cite id="ac_5">Note (5): Is there a separate user to manage special operation like backup (only dump/restore permissions), security officer (audit), administrator (add user/create database), etc.? Is it default or optional?
 * <cite id="ac_6">Note (6): Common Criteria certified product list.
 * <cite id="ac_7">Note (7): FirebirdSQL seems to only have SYSDBA user and DB owner. There are no separate roles for backup operator and security administrator.
 * <cite id="ac_8">Note (8): User can define a dedicated backup user but nothing particular in default install.
 * <cite id="ac_9">Note (9): Authentication methods.
 * <cite id="ac_10">Note (10): Informix Dynamic Server supports PAM and other configurable authentication. By default uses OS authentication.
 * <cite id="ac_11">Note (11): Authentication methods.
 * <cite id="ac_12">Note (12): With the use of Pervasive AuditMaster.
 * <cite id="ac_13">Note (13): User-based security is optional in Polyhedra, but when enabled can be enhanced to a role-based model with auditing.

Databases vs schemas (terminology)
The SQL specification defines what an "SQL schema" is; however, databases implement it differently. To compound this confusion the functionality can overlap with that of a parent database. An SQL schema is simply a namespace within a database; things within this namespace are addressed using the member operator dot ".". This seems to be a universal among all of the implementations.

A true fully (database, schema, and table) qualified query is exemplified as such: SELECT * FROM database.schema.table

Both a schema and a database can be used to isolate one table, "foo", from another like-named table "foo". The following is pseudo code:
 * SELECT * FROM database1.foo vs. SELECT * FROM database2.foo (no explicit schema between database and table)
 * SELECT * FROM [database1.]default.foo vs. SELECT * FROM [database1.]alternate.foo (no explicit database prefix)

The problem that arises is that former MySQL users will create multiple databases for one project. In this context, MySQL databases are analogous in function to PostgreSQL-schemas, insomuch as PostgreSQL deliberately lacks off-the-shelf cross-database functionality (preferring multi-tenancy) that MySQL has. Conversely, PostgreSQL has applied more of the specification implementing cross-table, cross-schema, and then left room for future cross-database functionality.

MySQL aliases schema with database behind the scenes, such that CREATE SCHEMA and CREATE DATABASE are analogs. It can therefore be said that MySQL has implemented cross-database functionality, skipped schema functionality entirely, and provided similar functionality into their implementation of a database. In summary, PostgreSQL fully supports schemas and multi-tenancy by strictly separating databases from each other and thus lacks some functionality MySQL has with databases, while MySQL does not even attempt to support standard schemas.

Oracle has its own spin where creating a user is synonymous with creating a schema. Thus a database administrator can create a user called PROJECT and then create a table PROJECT.TABLE. Users can exist without schema objects, but an object is always associated with an owner (though that owner may not have privileges to connect to the database). With the 'shared-everything' Oracle RAC architecture, the same database can be opened by multiple servers concurrently. This is independent of replication, which can also be used, whereby the data is copied for use by different servers. In the Oracle implementation, a 'database' is a set of files which contains the data while the 'instance' is a set of processes (and memory) through which a database is accessed.

Informix supports multiple databases in a server instance like MySQL. It supports the CREATE SCHEMA syntax as a way to group DDL statements into a single unit creating all objects created as a part of the schema as a single owner. Informix supports a database mode called ANSI mode which supports creating objects with the same name but owned by different users.

PostgreSQL and some other databases have support for foreign schemas, which is the ability to import schemas from other servers as defined in ISO/IEC 9075-9 (published as part of SQL:2008). This appears like any other schema in the database according to the SQL specification while accessing data stored either in a different database or a different server instance. The import can be made either as an entire foreign schema or merely certain tables belonging to that foreign schema. While support for ISO/IEC 9075-9 bridges the gap between the two competing philosophies surrounding schemas, MySQL and Informix maintain an implicit association between databases while ISO/IEC 9075-9 requires that any such linkages be explicit in nature.