October 8, 2024
Summary: Consider a switch from a commercial to an open source database. Discover the key differences and similarities between PostgreSQL and SQL Server.
Table of Contents
Introduction
PostgreSQL and SQL Server (or MSSQL) are widely used relational databases. Although they share several core traits, there are significant differences between them. This article provides a detailed rundown of the similarities and differences between PostgreSQL and SQL Server.
Among the most important distinctions is that PostgreSQL is open source, while SQL Server is owned and licensed by Microsoft. In addition, you will learn about the differences between the two systems regarding licensing and cost, ease of use, SQL syntax and compliance, data types, available features, performance, and security, among over other dozens topics covered in head-to-head comparisons.
It will benefit organizations thinking of switching from a commercial to an open source database but need more information on the possible trade-offs and advantages of the two systems. However, it is intended for anyone who is curious to learn more about relational databases.
Server Licensing Models
PostgreSQL
PostgreSQL is an open source database released under the PostgreSQL License, an Open Source Initiative Approved License. The use of PostgreSQL for any purpose, including commercial, is free. Under the PostgreSQL Global Development Group, PostgreSQL is available as free and open source software in perpetuity.
SQL Server
Microsoft SQL Server is available through a commercial license and can be licensed on a per-core or server and client access level (CAL) model. MSSQL is offered in two main editions, Enterprise Edition and Standard Edition, to meet organizations’ and individuals’ performance and price requirements. Licensing costs range from $3,586 for the Standard Edition to $13,748 for the Enterprise Edition (for two cores); the server and CAL model run $899 for the server plus $209 per user. A free version is available to students and developers for building and testing.
Data Types
PostgreSQL vs. SQL Server Data Types Comparison Table
| Data Type | PostgreSQL | SQL Server |
|---|---|---|
| 64-bit integer | BIGINT | BIGINT |
| Fixed length byte string | BYTEA | BINARY(n) |
| 1, 0 or NULL | BOOLEAN | BIT |
| Fixed length char string, 1 <= n <=8000 | CHAR(n) | CHAR(n) |
| Variable length char string, 1 <= n <=8000 | VARCHAR(n) | VARCHAR(n) |
| Variable length char string, <= 2GB | TEXT | VARCHAR(max) |
| Variable length byte string, 1 <= n <=8000 | BYTEA | VARBINARY(n) |
| Variable length byte string, <= 2GB | BYTEA | VARBINARY(max) |
| Variable length Unicode UCS-2 string | VARCHAR(n) | NVARCHAR(n) |
| Variable length Unicode UCS-2 data, <= 2GB | TEXT | NVARCHAR(max) |
| Variable length character data, <= 2GB | TEXT | TEXT |
| Variable length Unicode UCS-2 data, <= 2GB | TEXT | NTEXT |
| Double precision floating point number | DOUBLE PRECISION | DOUBLE PRECISION |
| Floating point number | DOUBLE PRECISION | FLOAT(p) |
| 32 bit integer | INTEGER | INTEGER |
| Fixed point number | NUMERIC(p,s) | NUMERIC(p,s) |
| Date includes year, month, and day | DATE | DATE |
| Date and time with fractional seconds | TIMESTAMP(p) | DATETIME, DATETIME2(p) |
| Date and time with time zone | TIMESTAMP(p) WITH TIME ZONE | DATETIMEOFFSET(p) |
| Date and time | TIMESTAMP(0) | SMALLDATETIME |
| Unsigned integer, 0 to 255 (8 bit) | SMALLINT | TINYINT |
| UUID (16 byte) | CHAR(16) | UNIQUEIDENTIFIER |
| Automatically updated binary data | BYTEA | ROWVERSION |
| Currency amount (32 bit) | MONEY | SMALLMONEY |
| Variable length binary data, <= 2GB | BYTEA | IMAGE |
| Geometric types | POINT, LINE, LSEG, BOX, PATH, POLYGON, CIRCLE | GEOMETRY |
Geographic Data
PostgreSQL
PostgreSQL does not have a native data type for geographic data. The open source PostGIS resource offers support for geographic objects.
SQL Server
SQL Server has the geography data type for storing geographic spatial data.
Case Sensitivity
PostgreSQL
PostgreSQL is case-sensitive for evaluating strings. The LOWER() function allows users to convert strings to all lowercase for evaluation purposes (there is also a similar UPPER() function). By default, PostgreSQL converts table and column names to lowercase unless you place those names in quotes. The context module provides a case-insensitive string data type context for comparing values.
SQL Server
SQL Server is case insensitive by default. Adjusting the SQL Server’s collation settings can change the case sensitivity. Set the collation settings for case sensitivity at the database or column level.
Index Types
PostgreSQL
PostgreSQL offers several options for index types, including B-tree, hash, Generalized Search Tree (GiST), Space Partitioned GiST, Generalized Inverted Index (GIN), and Block Range Index (BRIN). In addition, it supports expression indexes (indexes created with an expression or function rather than a column value) and partial indexes (indexes of part of a table).
SQL Server
SQL Server offers clustered and nonclustered indexes. Clustered indexes sort and store data rows in the table or view based on fundamental values (columns in the index definition). A table can have only one clustered index. Nonclustered indexes are stored separately from table data, and each key value entry has a pointer to the data. MSSQL automatically creates these indexes when you define PRIMARY KEY and UNIQUE constraints on table columns. The UNIQUE constraint creates a nonclustered index, while the PRIMARY KEY creates a clustered index unless one already exists.
Replication
PostgreSQL
PostgreSQL has Primary-Secondary replication. Replication can be synchronous or asynchronous. Asynchronous replication uses write-ahead logs (WALs) to share changes with the replica nodes. Streaming replication updates standby servers more immediately by streaming the WALs as they are created rather than waiting for the file to be filled.
Logical replication follows a publish and subscribe model, where changes are based on the data’s replication identity (a primary key) rather than its physical location, hence the name “logical replication.” Physical replication deals with files and directories without regard for the contents within those physical locations. PostgreSQL does not natively offer multi-master replication, but some third-party tools offer multi-master replication solutions.
SQL Server
SQL Server replication duplicates data from a Publisher server to a Subscriber and offers three types of replication:
- Transactional replication for server-to-server environments, where changes are delivered from the publisher to the subscriber as they occur.
- Merge replication for server-to-client environments or in situations where conflicts might occur, where data can be changed and tracked on either the publisher or subscriber and later synchronized.
- Snapshot replication is when data is updated infrequently or does not need to be changed incrementally, where data is duplicated precisely as it appears at a specific moment.
Replication in SQL Server can be a synchronous commit or asynchronous commit. The Enterprise edition offers peer-to-peer replication as an alternative solution to multi-master replication.
Clustering
PostgreSQL
PostgreSQL allows clusters of servers but does not natively support multi-master or active/active clusters. Tools such as repmgr allow for easy maintenance of PostgreSQL clusters.
SQL Server
SQL Server offers Windows Server Failover Clustering, which can be configured for both active/passive and active/active nodes. The Standard edition only supports two nodes for clusters; additional nodes require an upgrade to the Enterprise edition.
High Availability
PostgreSQL
PostgreSQL offers several solutions to ensure high availability for users, including shared disk failover, write-ahead log shipping, data partitioning and multiple replication methods. Tools like Patroni provide automatic failover to ensure high availability by monitoring and identifying database failure.
SQL Server
SQL Server includes several high-availability tools in its various editions. These include replication, log shipping, and failover clusters. Its Always On availability groups, offered with the Enterprise edition, provide automatic failover when certain conditions are met.
Views
PostgreSQL
PostgreSQL supports views – virtual tables that do not store data themselves. Updatable views are supported, but updates do not occur automatically unless they meet the following conditions:
- The query of that view must have precisely one section in the FROM clause, which can be a table or another updatable view.
- The selection list must not contain any window function, aggregate function, or set-returning function.
- The query must not contain one of the following clauses at the top level: HAVING, LIMIT, DISTINCT, WITH, INTERSECT, EXCEPT, OFFSET, AND LIMIT.
Views created with simple queries can be updated; ones made with complex queries cannot, but complex views can be updated using rules. Materialized views are also supported and the data in materialized views can be updated using the REFRESH MATERIALIZED VIEW statement.
SQL Server
SQL Server views can be used to restrict user access to data for security purposes. Both user-defined and system-defined views are supported. Views can be automatically updated using triggers. The data in a view can be updated when the modifications are made to a column from a single underlying base table and are referenced directly. Materialized views are known in SQL Server as Indexed Views; unlike materialized views in other relational databases, indexed views are synched to the underlying data and are thus updated automatically.
Triggers
PostgreSQL
PostgreSQL has advanced triggers. Supported triggering events include AFTER, BEFORE, and INSTEAD OF, which apply to INSERT, UPDATE, and DELETE events. When a trigger fires, it can execute complex SQL statements using functions. PostgreSQL can execute this dynamically.
SQL Server
SQL Server offers triggers for different types of database events:
- DML Triggers: for a data manipulation language (DML) specific event, such as inserting, updating, or deleting records. These triggers fire on events irrespective of the number of rows affected.
- DDL Triggers: for data definition language (DDL) events, such as CREATE, DROP, or ALTER statements. These are useful for preventing or auditing changes to the database schema.
Logon Triggers allow you to respond to user session establishment events. These triggers fire after successful authentication and before establishing the user session. They are helpful for auditing and controlling login activity.
Stored Procedures
PostgreSQL
PostgreSQL supports stored procedures as user-defined functions with a RETURN VOID clause. PostgreSQL supports stored procedures written in various languages alongside standard SQL syntax.
SQL Server
SQL Server supports stored procedures for languages supported by Microsoft .NET framework (common runtime languages or CLR, like VB, C#, or Python).
Full-Text Search
PostgreSQL
PostgreSQL offers advanced functionality for full-text search. It uses full-text indexing and dictionaries for faster searches. PostgreSQL stores pre-processed text documents as vector data types and processed queries as their dedicated type. Pre-processing parses text documents into linguistic units known as lexemes, which allows you to find case-insensitive variants of a word.
SQL Server
SQL Server offers full-text search as an optional component. Full-text indexes enable searches based on specific language rules. Searches are performed on columns or text data types (including char, varchar, nchar, nvarchar, text, ntext, image, xml, or varbinary(max) and FILESTREAM) using the T-SQL commands CONTAINS to match words and phrases and FREETEXT to match meaning. Thesaurus files can be used to help find synonyms of search terms. Full-text searches in SQL Server are not case sensitive.
Regular Expressions
PostgreSQL
PostgreSQL has three methods for evaluating regular expressions: LIKE, SIMILAR TO, and POSIX regular expressions.
SQL Server
SQL Server does not natively support regular expression evaluation; similar but limited results can be achieved using the T-SQL functions LIKE, SUBSTRING, and PATINDEX.
Partitioning
PostgreSQL
PostgreSQL offers built-in support for range, list, and hash partitioning. Range partitioning groups a table into ranges defined by a partition key column or set of columns – for example, by date range. List partitioning breaks a table into groups by explicitly listing predefined fundamental values in each partition.
SQL Server
SQL Server supports table and index partitioning. The data is partitioned horizontally and maps groups of rows into individual partitions. All partitions of a single index or table must reside in the same database and the table or index is treated as a single entity for queries and updates.
Identity Column
PostgreSQL
PostgreSQL introduced a new constraint feature in version 10 called GENERATED AS IDENTITY. This SQL-compliant variant of the SERIAL column allows you to assign a unique value to an identity column automatically.
For a SERIAL column to have a unique constraint or be a primary key, it must now be specified, just like other data types. Unique identifier columns are created using the data types smallserial, serial, and bigserial, similar to auto-increment features in different databases.
SQL Server
SQL Server’s identity column property creates an identity column for a table to generate critical values for rows. Two values are specified when it is made: seed (initial value for the first row) and increment (amount to increase value over the previous row). By default, both the seed and incremental values are 1. Each table can only contain one identity column. The uniqueness of the values is not guaranteed unless PRIMARY KEY or UNIQUE constraints are imposed.
Computed Column
PostgreSQL
PostgreSQL uses the term generated columns for computed columns. This feature was introduced with version 12. Generated columns can be physically stored when marked STORED; otherwise, they are not stored and are known as virtual.
CREATE TABLE table (
...,
computed_column GENERATED ALWAYS AS (expression) STORED
);
Generated columns cannot have an identity definition or be part of a partition key; they can only reference the current row and cannot use subqueries. Values cannot be specified using INSERT or UPDATE, but the keyword DEFAULT is accepted.
SQL Server
SQL Server computed columns are not physically stored in a table unless marked with the PERSISTED property; the column can only be persisted when the value is deterministic or always returns the same result.
ALTER TABLE table
ADD computed_column AS expression [PERSISTED];
If the computed column is deterministic and an acceptable data type, it can be used as a PRIMARY KEY or index but not as a DEFAULT or FOREIGN KEY constraint. Values cannot be specified using INSERT or UPDATE.
Integers
PostgreSQL
There are three kinds of integers in PostgreSQL: SMALLINT (small integer, a 2-byte type with a range from -32,768 to 32,767) INT (integer, a 4-byte type with a range from -2,147,483,648 to 2,147,483,647) BIGINT (a large-range integer: -9223372036854775808 to 9223372036854775807)
SQL Server
SQL SERVER supports standard SQL integer types BIGINT, INT, SMALLINT, and TINYINT. The range and storage size of each type is as follows:
PostgreSQL vs. SQL Server Integers Comparison Table
| Data type | Range | Storage |
|---|---|---|
| BIGINT | -263 (-9,223,372,036,854,775,808) to 263-1 (9,223,372,036,854,775,807) | 8 Bytes |
| INT | -231 (-2,147,483,648) to 231-1 (2,147,483,647) | 4 Bytes |
| SMALLINT | -215 (-32,768) to 215-1 (32,767) | 2 Bytes |
| TINYINT | 0 to 255 | 1 Byte |
Boolean Types
PostgreSQL
The PostgreSQL Boolean data type can have three states:
- TRUE
- FALSE
- NULL
SQL Server
The BIT data type in SQL SERVER represents true/false boolean data. A BIT field’s value is either 1, 0, or null.
NoSQL Capabilities
PostgreSQL
Like many other relational databases, PostgreSQL has added support for JSON data, the most common format for semi-structured data stored in NoSQL systems. However, because SQL is the only way to interact with a PostgreSQL database, it should not be considered NoSQL.
SQL Server
SQL Server has native JSON functions that enable you to parse JSON documents using standard SQL language. You can store JSON documents in an SQL Server and query JSON data as in a NoSQL database. Still, because SQL Server is an SQL database, it should not be considered NoSQL.
Analytical Functions
PostgreSQL
PostgreSQL supports various analytical functions, which perform aggregation on a set of rows. There are two types of analytical functions: window functions and aggregate functions. Aggregate functions perform aggregation and return a single aggregate value for a set of rows (like sum, avg, min, or max). Window functions return a single aggregate value for each of the rows.
PostgreSQL supports the following window functions:
| Function | Description |
|---|---|
| CUME_DIST | Return the relative rank of the current row |
| DENSE_RANK | Rank the current row within its partition without gaps |
| FIRST_VALUE | Return a value evaluated against the first row within its partition |
| LAG | Return a value from a specified physical offset row before the current row within the partition |
| LAST_VALUE | Return a value evaluated against the last row within its partition |
| LEAD | Return a value from a row that is offset rows after the current row within the partition |
| NTILE | Divide rows in a partition as equally as possible then assign each row an integer from 1 to the argument value |
| NTH_VALUE | Return a value evaluated against the nth row in an ordered partition |
| PERCENT_RANK | Return the relative rank of the current row |
| RANK | Rank the current row within its partition with gaps |
| ROW_NUMBER | Number the current row within its partition starting from 1. |
SQL Server
SQL Server’s analytic functions empower you to calculate moving averages, running totals, percentages, or top-N results directly within a group.
SQL Server supports the following analytic functions:
| Function | Description |
|---|---|
| CUME_DIST (Transact-SQL) | Calculate the cumulative distribution of a value within a group |
| FIRST_VALUE (Transact-SQL) | Return the first value in an ordered set of values |
| LAG (Transact-SQL) | Return value of a previous row to compare values without requiring a self-join |
| LAST_VALUE (Transact-SQL) | Return the last value in an ordered set of values |
| LEAD (Transact-SQL) | Return value of a subsequent row to compare values without requiring a self-join |
| PERCENTILE_CONT (Transact-SQL) | Calculate a percentile based on continuous distribution of column values |
| PERCENTILE_DISC (Transact-SQL) | Calculate a percentile based on discrete distribution of column values |
| PERCENT_RANK (Transact-SQL) | Calculate relative rank of a row within group |
Administration and GUI Tools
PostgreSQL
PostgreSQL can be administered through a GUI using Oracle’s SQL Developer, pgAdmin, OmniDB, DBeaver, and Navicat. Other GUI tools for monitoring health and performance include Nagios, Zabbix, Cacti, and Prometheus. SQLECTRON is a cross-platform option that is free and open source; it is compatible with several SQL databases, including SQL Server.
SQL Server
SQL Server can be administered through a GUI on Windows using SQL Server Management Studio (SSMS), which is free. SQL Operations Studio is a free, open source, cross-platform GUI for Mac. SQLECTRON is a free, open source, cross-platform option compatible with several SQL databases, including PostgreSQL.
Performance
PostgreSQL
PostgreSQL offers speed and performance across data sets of all sizes and it regularly outperforms other databases in both online transaction processing (OLTP) and online analytical processing (OLAP) speeds. It offers multi-version concurrency control (MVCC), processing multiple transactions simultaneously, with fewer deadlocks than SQL Server. PostgreSQL offers many tools and parameters that allow users to monitor and optimize database performance.
SQL Server
SQL Server prides itself on the speed of its analytical and transaction processing. However, because the SQL Server user agreement prohibits the publication of benchmark testing without Microsoft’s prior written approval, head-to-head comparisons with other database systems are rare. Among the features SQL Server highlights for optimizing performance and speed is its In-Memory OLTP, which takes advantage of in-memory data tables that perform better than writing directly to disk. The SQL Server Standard edition has some performance limitations for memory, partitioning, indexing, and other functionalities that require upgrading to the Enterprise version.
Concurrency
PostgreSQL
PostgreSQL has a well-developed multi-version concurrency control (MVCC) that handles multiple procedures simultaneously. MVCC provides snapshots of database info to avoid showing inconsistencies caused by simultaneous transactions or the locking of data that occurs in other database systems. It uses Serializable Snapshot Isolation (SSI) to guarantee transaction isolation.
SQL Server
SQL Server has a less fully developed multi-version concurrency control system and, by default, relies on data locking to prevent errors from simultaneous transactions. To improve performance, it implements optimistic concurrency. This approach skips row locking and instead verifies any changes against a cached version, assuming conflicts are rare.
Adoption
PostgreSQL
PostgreSQL is the world’s most advanced open source database. Businesses across the globe are using PostgreSQL for mission-critical workloads. The PostgreSQL community and a few companies are ensuring that PostgreSQL adoption continues to expand globally.
SQL Server
SQL Server is popular with enterprises that rely on Microsoft products. It saw an increase in market share over the past two decades as Microsoft pushed it with its Windows Servers. However, with more and more enterprises shifting to open source in recent years, the popularity curve of SQL servers is becoming flatter and flatter.
Environment and Stack
PostgreSQL
PostgreSQL is popular with the LAPP stack (Linux, Apache, PostgreSQL, and PHP/Python. The LAPP stack is growing in popularity; large-platform service providers like Amazon and VMware provide services with readily installed LAPP stack modules.
SQL Server
SQL Server is a popular component of the Microsoft stack. It comprises Microsoft technologies like Microsoft WPF, ASP.NET, SharePoint, and Office 365.
Scheduling Tasks
PostgreSQL
PostgreSQL doesn’t provide a built-in job scheduler like other SQL databases do. Recurring tasks require external tools like pgAgent, cron, or pg_cron on Linux, and Task Scheduler or SQLBackupAndFTP on Windows.
SQL Server
The SQL Server Management Studio schedules tasks in the SQL Server.
Access Methods
PostgreSQL
PostgreSQL is compatible with the following access methods, protocols, and APIs for accessing its data: ADO.NET, JDBC, ODBC, and the native C library. It also supports a streaming API for binary large objects (BLOBs).
SQL Server
SQL Server is compatible with the following access methods, protocols, and APIs for accessing its data: ADO.NET, JDBC, ODBC, OLE DB, and TDS.
Bulk Collect and Binds
| Feature | PostgreSQL | SQL Server |
|---|---|---|
| Bulk Collect | PostgreSQL does not have syntax for bulk collect nor any close functional equivalent. Instead, if working within a single SQL statement, you can create a temporary table with PL/PgSQL code or use a common table expression (CTE or WITH query). | There is no syntax for bulk collect in SQL Server. One alternative is to use a temporary table and a cursor. |
| Binds | Unlike other relational databases like Oracle, PostgreSQL does not support bind variables. Instead, PostgreSQL uses the PREPARE statement to achieve similar results. | SQL Server supports bind variables. Each parameter marker in an SQL statement must be bound to a variable before the statement can be executed using the SQLBindParameter function. Parameters can also be bound to arrays of program variables to process an SQL statement in batches. SQL Server also supports defining names for stored procedure parameters. |
Synonyms
SQL Server supports synonyms. Synonyms provide a layer of abstraction that protects a client application from changes made to base objects. A synonym belongs to a schema; like other objects in a schema, its name must be unique. Binding is by name only; if a base object is modified, dropped, or replaced, the missing reference will only be found at run-time. PostgreSQL does not support synonyms.