pytest-postgresql 9.0.0

How does it work

The plugin provides two main types of fixtures:

1. Client Fixtures

These provide a connection to a database for your tests.

• postgresql - A function-scoped fixture. It returns a connected psycopg.Connection. After each test, it terminates leftover connections and drops the test database to ensure isolation.

• postgresql_async - The async counterpart. It returns a connected psycopg.AsyncConnection. Requires pytest-postgresql[async] (pytest-asyncio >= 1.4), and each test must be marked with @pytest.mark.asyncio.

Async fixtures

postgresql_async and custom factories created with factories.postgresql_async are async generator fixtures using pytest_asyncio.fixture.

Minimum versions when installing manually instead of via [async]:

pytest-asyncio >= 1.4
aiofiles >= 23.0        # only for async SQL file loading

If pytest-asyncio is missing, fixture setup raises ImportError.

Async SQL file loading

Process and noproc fixtures always populate their template database synchronously during session setup (via DatabaseJanitor.load()), even when you use postgresql_async as the client fixture. SQL Path entries in a process fixture load list are executed with the sync sql() loader.

Use sql_async (requires aiofiles from the [async] extra) when you call AsyncDatabaseJanitor.load() directly with a Path. Callable loaders passed to AsyncDatabaseJanitor.load() may be sync or async; return values that are awaitable are awaited automatically.

from pathlib import Path
from pytest_postgresql import factories

postgresql_my_proc = factories.postgresql_proc(load=[Path("schema.sql")])
postgresql_my_async = factories.postgresql_async("postgresql_my_proc")

2. Process Fixtures

These manage the PostgreSQL server lifecycle.

• postgresql_proc - A session-scoped fixture that starts a PostgreSQL instance on its first use and stops it when all tests are finished.

• postgresql_noproc - A fixture for connecting to an already running PostgreSQL instance (e.g., in Docker or CI).

Customizing Fixtures

You can create additional fixtures using factories:

from pytest_postgresql import factories

# Create a custom process fixture
postgresql_my_proc = factories.postgresql_proc(
    port=None, unixsocketdir='/var/run')

# Create a client fixture that uses the custom process
postgresql_my = factories.postgresql('postgresql_my_proc')

# Async client fixture (requires pytest-postgresql[async], pytest-asyncio >= 1.4)
postgresql_my_async = factories.postgresql_async('postgresql_my_proc')

Pre-populating the database for tests

If you want the database to be automatically pre-populated with your schema and data, there are two levels you can achieve it:

1. Per test: In a client fixture, by using an intermediary fixture.

2. Per session: In a process fixture.

The process fixture accepts a load parameter, which supports:

• SQL file paths: Loads and executes the SQL files.

• Loading functions: A callable or an import string (e.g., "path.to.module:function"). These functions receive host, port, user, dbname, and password and must perform the connection themselves (or use an ORM).

The process fixture pre-populates the database once per session into a template database. The client fixture then clones this template for each test, which significantly speeds up your tests.

from pathlib import Path
postgresql_my_proc = factories.postgresql_proc(
    load=[
        Path("schemafile.sql"),
        "import.path.to.function",
        load_this_callable
    ]
)

Defining pre-population on the command line:

pytest --postgresql-load=path/to/file.sql --postgresql-load=path.to.function

If a loaded .sql file contains statements that cannot run inside a transaction block (for example CREATE DATABASE), enable autocommit on the loader connection. This can be set without writing a custom loader, via the factory argument, the command line, or pytest.ini:

postgresql_my_proc = factories.postgresql_proc(load=[Path("with_create_db.sql")], load_autocommit=True)

pytest --postgresql-load-autocommit

Connecting to an existing PostgreSQL database

To connect to an external server (e.g., running in Docker), use the postgresql_noproc fixture.

For async tests against an external server, create a client fixture with factories.postgresql_async("postgresql_noproc") (see tests/examples/test_drop_test_database_async.py).

postgresql_external = factories.postgresql('postgresql_noproc')

By default, it connects to 127.0.0.1:5432.

Using a maintenance database other than postgres

Creating and dropping the test databases requires a connection to a database that already exists - by default postgres. If the test role merely lacks the privilege, GRANT CONNECT ON DATABASE postgres TO myuser is the simpler fix. When postgres is not reachable at all - behind a connection pooler with a fixed database list, or on a managed server that does not expose it - point the noproc fixture at another database:

pytest --postgresql-maintenance-dbname=my_existing_db

postgresql_external = factories.postgresql_noproc(maintenance_dbname="my_existing_db")

The database is only connected to, never created, modified or dropped. Avoid template1: CREATE DATABASE clones it when no template is given, and PostgreSQL does not expect the source database to be in use while it is being copied.

Chaining fixtures

You can chain multiple postgresql_noproc fixtures to layer your data pre-population. Each fixture in the chain will create its own template database based on the previous one.

from pytest_postgresql import factories

# 1. Start with a process or a no-process base
base_proc = factories.postgresql_proc(load=[load_schema])

# 2. Add a layer with some data
seeded_noproc = factories.postgresql_noproc(depends_on="base_proc", load=[load_data])

# 3. Add another layer with more data
more_seeded_noproc = factories.postgresql_noproc(depends_on="seeded_noproc", load=[load_more_data])

# 4. Use the final layer in your test
client = factories.postgresql("more_seeded_noproc")

Using SQLAlchemy

This example shows how to create an SQLAlchemy session fixture:

from typing import Iterator
import pytest
from psycopg import Connection
from sqlalchemy import create_engine
from sqlalchemy.orm import Session, sessionmaker, scoped_session
from sqlalchemy.pool import NullPool

@pytest.fixture
def db_session(postgresql: Connection) -> Iterator[Session]:
    """Session for SQLAlchemy."""
    user = postgresql.info.user
    host = postgresql.info.host
    port = postgresql.info.port
    dbname = postgresql.info.dbname

    connection_str = f'postgresql+psycopg://{user}:@{host}:{port}/{dbname}'
    engine = create_engine(connection_str, echo=False, poolclass=NullPool)

    # Assuming you use a Base model
    from my_app.models import Base
    Base.metadata.create_all(engine)

    SessionLocal = scoped_session(sessionmaker(bind=engine))
    yield SessionLocal()

    SessionLocal.close()
    Base.metadata.drop_all(engine)

Advanced Usage: DatabaseJanitor

DatabaseJanitor is an advanced API for managing database state outside of standard fixtures. It is used by projects like Warehouse (pypi.org).

import psycopg
from pytest_postgresql.janitor import DatabaseJanitor

def test_manual_janitor(postgresql_proc):
    with DatabaseJanitor(
        user=postgresql_proc.user,
        host=postgresql_proc.host,
        port=postgresql_proc.port,
        dbname="my_custom_db",
        password="secret_password",
    ):
        with psycopg.connect(
            dbname="my_custom_db",
            user=postgresql_proc.user,
            host=postgresql_proc.host,
            port=postgresql_proc.port,
            password="secret_password",
        ) as conn:
            # use connection
            pass

Advanced Usage: AsyncDatabaseJanitor

AsyncDatabaseJanitor is the async counterpart to DatabaseJanitor. Use it when managing database state with psycopg.AsyncConnection outside of standard fixtures. It requires psycopg (a core dependency). Install pytest-postgresql[async] when you need aiofiles for SQL file loading via sql_async, or pytest-asyncio for pytest async tests.

import pytest
import psycopg
from pytest_postgresql.janitor import AsyncDatabaseJanitor

@pytest.mark.asyncio
async def test_manual_async_janitor(postgresql_proc):
    async with AsyncDatabaseJanitor(
        user=postgresql_proc.user,
        host=postgresql_proc.host,
        port=postgresql_proc.port,
        dbname="my_custom_db",
        password="secret_password",
    ):
        async with await psycopg.AsyncConnection.connect(
            dbname="my_custom_db",
            user=postgresql_proc.user,
            host=postgresql_proc.host,
            port=postgresql_proc.port,
            password="secret_password",
        ) as conn:
            # use async connection
            pass

Connecting to PostgreSQL in Docker

To connect to a Docker-run PostgreSQL, use the noproc fixture.

docker run --name some-postgres -e POSTGRES_PASSWORD=mysecret -d postgres

In your tests:

from pytest_postgresql import factories

postgresql_in_docker = factories.postgresql_noproc()
postgresql = factories.postgresql("postgresql_in_docker", dbname="test")

def test_docker(postgresql):
    with postgresql.cursor() as cur:
        cur.execute("SELECT 1")

Run with:

pytest --postgresql-host=172.17.0.2 --postgresql-password=mysecret

Basic database state for all tests

You can define a load function and pass it to your process fixture factory:

import psycopg
from pytest_postgresql import factories

def load_database(**kwargs):
    with psycopg.connect(**kwargs) as conn:
        with conn.cursor() as cur:
            cur.execute("CREATE TABLE stories (id serial PRIMARY KEY, name varchar);")
            cur.execute("INSERT INTO stories (name) VALUES ('Silmarillion'), ('The Expanse');")

postgresql_proc = factories.postgresql_proc(load=[load_database])
postgresql = factories.postgresql("postgresql_proc")

def test_stories(postgresql):
    with postgresql.cursor() as cur:
        cur.execute("SELECT count(*) FROM stories")
        assert cur.fetchone()[0] == 2

The process fixture populates the template database once, and the client fixture clones it for every test. This is fast, clean, and ensures no dangling transactions. This approach works with both postgresql_proc and postgresql_noproc.