tSQLt vs pgTAP

Quick verdict

tSQLt is an open source (Apache 2.0) unit testing framework for SQL Server, implemented as T-SQL objects plus a CLR assembly that you install into a development database. Tests are stored procedures grouped into test classes (schemas); each test runs inside a transaction that is rolled back afterwards. Redgate sponsors the project and sells SQL Test, an SSMS front end built on it. The latest release on tsqlt.org is V1.0.8083.3529 (17 February 2022).

pgTAP is a PostgreSQL extension, maintained by David E. Wheeler and distributed through PGXN, that adds test functions emitting TAP (Test Anything Protocol) output. Tests can be plain SQL scripts that call plan(), assertions and finish(), or xUnit-style test functions run by runtests(). Suites are run with pg_prove, a Perl command-line tool from CPAN. Version 1.3.4 (4 October 2025) is the latest release, and 1.3.5 is in development. Its README grants permissive, PostgreSQL-style terms.

Side by side

Key differences

Isolation with test doubles versus assertions on everything

tSQLt is built around isolating the unit under test. FakeTable replaces a real table with an empty copy without constraints, so a test inserts only the two or three columns it cares about. SpyProcedure replaces a dependent procedure and records how it was called, and FakeFunction does the same for functions. This makes it practical to test one stored procedure in a large legacy database without building valid data for every foreign key:

-- T-SQL (tSQLt): one test in a test class
EXEC tSQLt.NewTestClass 'testOrders';
GO
CREATE PROCEDURE testOrders.[test GetOrderTotal sums order lines]
AS
BEGIN
    EXEC tSQLt.FakeTable 'dbo.OrderLines';
    INSERT INTO dbo.OrderLines (OrderID, Amount) VALUES (1, 10.00), (1, 5.00);

    DECLARE @actual money = dbo.GetOrderTotal(1);

    EXEC tSQLt.AssertEquals 15.00, @actual;
END;
GO
EXEC tSQLt.Run 'testOrders';

pgTAP has no faking layer. Instead it offers a very wide set of assertions, many of them about the schema itself: that tables, columns, keys, indexes and functions exist with the expected definitions, and that owners, privileges and row-level security policies are what you expect. That makes it well suited to checking every migration, not only function behaviour. Tests insert their own rows inside a transaction that is rolled back:

-- PostgreSQL (pgTAP): a plain SQL test script
BEGIN;
SELECT plan(3);

SELECT has_table('public', 'orders', 'orders table exists');
SELECT col_not_null('public', 'orders', 'customer_id', 'customer_id is NOT NULL');

INSERT INTO order_lines (order_id, amount) VALUES (1, 10.00), (1, 5.00);
SELECT results_eq(
    'SELECT order_total(1)',
    $$VALUES (15.00::numeric)$$,
    'order_total sums order lines'
);

SELECT * FROM finish();
ROLLBACK;

Installing and running

tSQLt installs into each development database by script or by a SQL Server version-specific DACPAC (added in V1.0.7942, September 2021, which also certified SQL Server on Linux). Its quick start says to run PrepareServer.sql once per server with sysadmin rights; it enables CLR and installs a certificate so strict CLR security does not need to be turned off. The project is clear that tSQLt should never be installed in production. Tests run inside the database with tSQLt.Run or tSQLt.RunAll, and results can be written as XML for a CI server.

pgTAP is a normal PostgreSQL extension: build it from source with make and pg_config (or use a package), then run CREATE EXTENSION pgtap in the test database, which typically needs superuser rights. Tests are files run by pg_prove, which calls psql, can run several files in parallel with -j, and can execute xUnit-style test functions with --runtests. Because pg_prove is Perl from CPAN, CI images need Perl and the TAP::Parser::SourceHandler::pgTAP distribution.

Managed cloud databases

This is where the two differ most in practice. tSQLt's downloads page offers the older 1.0.5873.27393 build as "the version working with SQL 2005 (and currently Azure SQL Databases)" and makes no compatibility claim for the latest build, which relies on a CLR assembly and a server certificate. Support for Azure SQL Managed Instance is not documented. If your target is Azure SQL Database, one option is to run the tSQLt suite against SQL Server in a container or VM in CI, and confirm with the project before installing the current build on the cloud database itself.

pgTAP works on any PostgreSQL where you can create the extension. Managed services decide which extensions they allow, so check your provider's extension list; where pgtap is not offered, one option is to run the suite against a PostgreSQL container of the same major version in CI.

Project activity and ecosystem

tSQLt has been quiet since V1.0.8083.3529 in February 2022. In our view it is stable rather than abandoned: it remains the framework underneath Redgate SQL Test, and much existing T-SQL test code depends on it. Still, factor in that newer SQL Server releases are not explicitly addressed in its release notes. pgTAP has kept pace with PostgreSQL: 1.3.4 fixed upgrade paths and a test failure on PostgreSQL 18, and 1.3.5 is in development. Its TAP output plugs into any TAP harness, while tSQLt's XML output plugs into common CI servers.

Pricing and licensing

tSQLt is free and open source under the Apache License 2.0. Redgate SQL Test, an optional SSMS add-in built on tSQLt, is a paid product: Redgate lists it at $303 per user per year for 1-4 users, and it is included in SQL Toolbelt Essentials ($1,410 per user per year for 1-4 users). The tSQLt downloads page links a 28-day SQL Test trial.

pgTAP is free under permissive terms in its README that allow use, copying, modification and distribution for any purpose without fee. The pg_prove runner is also free from CPAN. There is no paid edition of either.

Pricing checked on the vendors' official pages on 7 November 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You prefer to test the database from your application's own test framework: use Testcontainers for throwaway databases, or DbUnit on Java.
• You need data quality tests on warehouse models rather than unit tests of database code: see Datafold vs dbt tests.
• You need large volumes of realistic data to test against, not assertions: see Redgate SQL Data Generator vs dbForge Data Generator.
• You run MySQL or Oracle: neither framework applies; test from application code or with engine-specific tools.

Final recommendation

Frequently asked questions

Sources

• tSQLt home
• tSQLt quick start (installation)
• tSQLt downloads
• tSQLt release notes
• tSQLt GitHub repository (Apache 2.0)
• Redgate SQL Test
• pgTAP documentation
• pg_prove documentation
• pgTAP GitHub repository
• pgTAP Changes (release notes)

Checked November 2026.

How we research comparisons: our editorial method.