Database Testing
Xata is a serverless database platform built on PostgreSQL with a TypeScript SDK, full-text search, branch-based development workflows, and an HTTP API. Its branch feature — where every branch gets an isolated database — makes it particularly interesting for testing: you can create a branch per pull request and get
Supabase
Row Level Security is one of Supabase's most powerful features — and one of the most dangerous to get wrong. A misconfigured RLS policy can silently expose every row in a table to every authenticated user, or lock out legitimate access entirely. Neither failure is obvious until something goes
TypeORM
```tldr TypeORM testing spans two distinct strategies: fast unit tests that mock the DataSource and repositories, and slower but trustworthy integration tests that run against a real database. This post walks through both approaches — from validating entity schemas with in-memory SQLite to spinning up PostgreSQL with TestContainers — and gives
TestContainers
Testcontainers eliminates the gap between mocked database behavior and real database behavior by spinning up actual Docker containers during test runs. This post covers the full setup for Postgres, Redis, and MongoDB in both Node.js and Python, including parallel container execution, GitHub Actions integration, and concrete techniques to keep
Prisma
This post covers two complementary strategies for testing Prisma ORM: fast unit tests using jest.mock to stub @prisma/client, and reliable integration tests using TestContainers to spin up a real Postgres instance. You'll learn how to keep your test suite both fast and trustworthy by knowing when
Hasura
Hasura generates a GraphQL API directly from your PostgreSQL schema, which means your tests must cover things that don't exist in hand-written APIs: role-based permission rules, relationship traversal, computed fields backed by SQL functions, and event triggers. This post shows a complete pytest-based testing strategy
Database
Untested migrations are one of the highest-risk deployments in software engineering — a bad migration can corrupt production data in seconds with no undo. This post covers a systematic approach to testing forward migrations, rollback paths, data integrity invariants, and zero-downtime patterns like expand/contract, all using TestContainers so
Drizzle
Drizzle ORM's SQL-first design makes it highly testable: you can run queries against in-memory SQLite for fast unit tests, swap in a real Postgres container for integration tests with minimal code changes, and validate your schema definitions statically. This post walks through all three layers and
Rust
Database tests are the ones developers skip first. They're slow, they need real infrastructure, they leave state behind that breaks subsequent runs, and they're painful to set up in CI. SQLx and the Rust testing ecosystem have largely solved these problems — #[sqlx::test] auto-migrates and
TimescaleDB
TimescaleDB extends PostgreSQL with time-series superpowers—automatic partitioning via hypertables, continuous aggregates, and time-bucket functions. Since it's built on PostgreSQL, most Postgres testing tools work. But TimescaleDB-specific features require specific testing approaches. This guide covers all of them. TimescaleDB Testing Stack TimescaleDB runs as a
Database
Neon's branching API makes test isolation cheap — create a branch per PR in seconds, run tests, delete it. But serverless Postgres has specific behaviors around cold starts, connection pooling, and branch state that need explicit testing coverage. Key Takeaways Branches are the unit of test isolation. Neon branches
Database Testing
PostgreSQL is the world's most popular open-source relational database — and testing PostgreSQL-backed applications is one of the most important skills a backend engineer can have. This guide covers the full spectrum: fast in-memory tests with pg-mem, realistic integration tests with Testcontainers, and patterns that