{
  "video_id": "reddit_1u77h7h",
  "channel_slug": "programming",
  "channel_handle": "r/programming",
  "title": "Don't run SQL migrations in tests: How I sped up the test suite by 2x",
  "url": "https://www.reddit.com/r/programming/comments/1u77h7h/dont_run_sql_migrations_in_tests_how_i_sped_up/",
  "external_url": "https://gaultier.github.io/blog/I_sped_up_the_test_suite_by_x2.html",
  "upload_date": "20260616",
  "published_at": "2026-06-16T08:18:40+00:00",
  "transcript": "\n\n--- Top Comments ---\n\n\n[57 upvotes] We use template databases with Postgres and it works like a charm. Migrate once, then treat the migrated DB as template. Create and tear down separate (logical) DBs for each test, using the template.\n\nThis article has a brief write-up of the strategy: [https://gajus.com/blog/setting-up-postgre-sql-for-running-integration-tests#template-databases](https://gajus.com/blog/setting-up-postgre-sql-for-running-integration-tests#template-databases)\n\n[18 upvotes] Other options: transactions and rollback (if you don't make explicit commits), multiple levels of transactions (so that you just roll back the outermost one that you own after the test).\n\nOr my favourite: write your tests so that they work with a populated database. No need to reset the database if your tests don't assume that the database is empty - and actually has data in the same way any real application does.",
  "transcript_chars": 914,
  "ingested_at": "2026-06-16T13:30:46.005025+00:00",
  "source": "reddit",
  "yt_meta": {
    "score": 70,
    "upvote_ratio": 0.83,
    "num_comments": 18,
    "author": "broken_broken_",
    "is_self": false
  }
}