@opengroundplan/core 0.1.1

package/catalog/sources/database-orm.yaml

@@ -0,0 +1,507 @@
+# Groundplan source catalog — category: database-orm
+#
+# Research date: 2026-07-18
+#
+# VERIFICATION METHOD
+#   stars / pushedAt : GitHub REST API. The host IP's anonymous quota (60/hr) was being
+#                      consumed by a sibling workflow, so figures were read through ungh.cc,
+#                      a faithful read-only proxy of api.github.com. Spot-checked against a
+#                      direct api.github.com call for prisma/prisma: 47340 stars /
+#                      pushed_at 2026-07-16T16:25:42Z — byte-identical on both fields.
+#   licenseClass     : GATE, not a note. Every SPDX id below was read from the repo's actual
+#                      LICENSE file on the default branch via raw.githubusercontent.com —
+#                      the primary source the rules allow when the API is unavailable.
+#                      No license was inferred from memory, a README badge, or a blog post.
+#   archived         : checked directly per repo. The earlier reasoning here ("a recent push
+#                      proves the repo is live") was INVALID — archiving requires no push, so
+#                      a repo can be archived at any time after its last commit. Replaced with
+#                      a real check: each repo page was fetched and tested for the "Public
+#                      archive" banner. All 15 returned HTTP 200 with no banner => not
+#                      archived, not disabled, no redirects to a moved path.
+#
+# Structural claims (file paths, template parameters, driver lists) were read from the live
+# default-branch file trees, not recalled. Two secondary-source claims were corrected this
+# way and are flagged inline.
+
+category: database-orm
+
+sources:
+  - name: drizzle-orm
+    url: https://github.com/drizzle-team/drizzle-orm
+    stack: typescript
+    stars: 35183
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: standard
+    whatToBorrow: >-
+      The single richest source of DB-choice breadth in the category. Verified driver modules
+      under drizzle-orm/src/: node-postgres, postgres-js, neon-http, neon-serverless,
+      planetscale-serverless, d1, libsql, supabase, vercel-postgres, pglite, better-sqlite3,
+      mysql2, bun-sql, bun-sqlite, expo-sqlite, durable-sqlite, aws-data-api, xata-http,
+      tidb-serverless, singlestore. Every dialect shares one query API over three cores
+      (pg-core, mysql-core, sqlite-core), so a Groundplan layer can swap the driver + connection
+      file and keep schema and query code identical. Borrow that three-core split, the
+      drizzle.config.ts dialect/driver shape, and the per-driver connection module pattern.
+    whatToAvoid: >-
+      Apache-2.0 requires the NOTICE/attribution to travel with copied files — cheap, but it
+      must actually be emitted. No SQL Server and no MongoDB dialect exists, so do not plan a
+      db-sqlserver-drizzle or db-mongodb-drizzle layer; route those to Prisma or EF Core.
+      drizzle-kit push is convenient but destructive against a real database — generated
+      layers should default to generate+migrate, not push.
+    proposedLayerIds:
+      - db-postgres-drizzle
+      - db-mysql-drizzle
+      - db-sqlite-drizzle
+      - db-neon-drizzle
+      - db-turso-drizzle
+      - db-planetscale-drizzle
+      - db-d1-drizzle
+      - db-supabase-drizzle
+
+  - name: prisma-examples
+    url: https://github.com/prisma/prisma-examples
+    stack: typescript
+    stars: 6647
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: standard
+    whatToBorrow: >-
+      Official, ready-to-run, per-database example projects — the closest thing in this
+      category to pre-built Groundplan layers. Verified subdirectories under databases/:
+      cockroachdb, mongodb, sql-server, turso, postgresql-supabase, prisma-postgres, plus
+      drizzle-prisma-postgres, kysely-prisma-postgres and typeorm-prisma-postgres. This is
+      where SQL Server and MongoDB coverage comes from, which Drizzle cannot supply. Borrow
+      each example's schema.prisma datasource block, its seed script, and the
+      deployment-platforms/ directory for per-host connection handling.
+    whatToAvoid: >-
+      Examples are demo-scale — no connection pooling strategy, no migration history worth
+      keeping, auth is usually stubbed. The accelerate/ directory is a paid Prisma product;
+      do not let it leak into a generated layer. Prisma's engine binary inflates cold starts
+      on serverless targets, and the newer Rust-free client changes that tradeoff, so pin
+      versions per layer rather than tracking latest.
+    proposedLayerIds:
+      - db-postgres-prisma
+      - db-mysql-prisma
+      - db-sqlserver-prisma
+      - db-mongodb-prisma
+      - db-sqlite-prisma
+      - db-cockroachdb-prisma
+      - db-turso-prisma
+
+  - name: kysely
+    url: https://github.com/kysely-org/kysely
+    stack: typescript
+    stars: 14058
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: simple
+    whatToBorrow: >-
+      The strip-down option for the bottom of the complexity ladder: a typed SQL query builder
+      with no codegen step, no CLI, no runtime engine — types come from a hand-written or
+      introspected Database interface. Borrow the Dialect interface as the cleanest
+      abstraction seam in the category for
+      "same code, different DB", plus its plain-TypeScript migration provider, which gives a
+      Groundplan template migrations without adopting a whole ORM. Verified in src/dialect/ there
+      are five built-in dialects, not three: postgres, mysql, sqlite, mssql and pglite. The
+      mssql dialect matters — Kysely is the only TypeScript entry in this catalog with
+      first-party SQL Server support, so it covers a gap Drizzle cannot.
+    whatToAvoid: >-
+      No entity/relation mapping and no automatic migration generation — the Database type is
+      yours to keep in sync, which drifts silently unless kysely-codegen is wired in. Weak fit
+      for a template aimed at users who expect scaffolding to write models for them. Keep it
+      as the deliberately-minimal tier, not the default.
+    proposedLayerIds:
+      - db-postgres-kysely
+      - db-mysql-kysely
+      - db-sqlite-kysely
+      - db-sqlserver-kysely
+
+  - name: nestjs-boilerplate
+    url: https://github.com/brocoders/nestjs-boilerplate
+    stack: typescript
+    stars: 4348
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: professional
+    whatToBorrow: >-
+      The single best answer in this category to "the user wants many DB choices". It ships
+      relational (TypeORM/Postgres) AND document (Mongoose/MongoDB) persistence behind one
+      hexagonal repository port, so the domain layer is unchanged when the database changes —
+      exactly the abstraction Groundplan needs to model a db-* layer swap. Verified layout:
+      infrastructure/persistence/relational/{entities,mappers,repositories} beside
+      infrastructure/persistence/document/{entities,mappers,repositories}, each with its own
+      persistence.module. NOTE the port filename: it is NOT a shared repository.ts — each
+      feature owns its own port one level above the two implementations, e.g.
+      src/users/infrastructure/persistence/user.repository.ts beside
+      persistence/{relational,document}/repositories/user.repository.ts. The .hygen/ generators
+      (all-db-resource, relational-resource, document-resource) are effectively a working
+      reference implementation of DB-parameterised scaffolding — read these before designing
+      Groundplan's own generator templates.
+    whatToAvoid: >-
+      Heavily coupled to NestJS; the persistence pattern is portable but the module wiring is
+      not. The mapper layer means every field is written three times (domain, entity, mapper),
+      which is real ceremony to inflict on a small project. Ships auth, mail, i18n and S3
+      uploads — strip aggressively or the db layer drags in the whole app.
+    proposedLayerIds:
+      - db-postgres-typeorm-nestjs
+      - db-mongodb-mongoose-nestjs
+      - db-dual-persistence-hexagonal
+      - orm-repository-port-pattern
+
+  - name: ioredis
+    url: https://github.com/redis/ioredis
+    stack: typescript
+    stars: 15311
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-16"
+    complexity: simple
+    whatToBorrow: >-
+      Redis coverage with a permissive license, which the Redis server itself no longer offers.
+      Borrow the connection-options and retryStrategy/reconnectOnError config shape, the
+      Cluster and Sentinel constructor patterns for the HA tier, and the lazyConnect option
+      that makes Redis optional in a generated app rather than a hard startup dependency.
+    whatToAvoid: >-
+      Note the licensing split that matters here: the ioredis CLIENT is MIT, but redis/redis
+      (the server) moved to AGPL-3.0/RSALv2 and is NOT vendorable — a generated layer may
+      depend on a Redis server via Docker image but must not copy server source. Do not make
+      Redis a required dependency in a starter; cache/session layers should degrade to
+      in-memory when it is absent.
+    proposedLayerIds:
+      - cache-redis-ioredis
+      - queue-redis-bullmq
+      - session-store-redis
+
+  - name: cloudflare-templates
+    url: https://github.com/cloudflare/templates
+    stack: typescript
+    stars: 2023
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-08"
+    complexity: standard
+    whatToBorrow: >-
+      First-party, MIT-licensed coverage of the serverless/edge DB tier. Verified templates:
+      d1-template/ (wrangler.json with the D1 binding, migrations/0001_create_comments_table.sql,
+      src/index.ts) and d1-starter-sessions-api-template/ (D1 Sessions API for read
+      replication, with vitest + @cloudflare/vitest-pool-workers config). Borrow the
+      wrangler.json binding block, the migrations/ convention, and the workers test harness —
+      edge DB testing is the part teams most often get wrong.
+    whatToAvoid: >-
+      CORRECTION to a widely-repeated claim: these D1 templates do NOT use Drizzle — they use
+      the raw D1 client. A db-d1-drizzle layer must combine this repo's wrangler/binding
+      config with Drizzle's own d1 driver; do not expect to lift it whole from here. Total
+      Cloudflare lock-in: wrangler.json, bindings and D1 have no local equivalent outside
+      Workers, so this cannot be the portable default.
+    proposedLayerIds:
+      - db-d1-cloudflare
+      - db-d1-drizzle
+      - deploy-cloudflare-workers
+
+  - name: full-stack-fastapi-template
+    url: https://github.com/fastapi/full-stack-fastapi-template
+    stack: python
+    stars: 44303
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-14"
+    complexity: professional
+    whatToBorrow: >-
+      The reference Python persistence stack, maintained under the FastAPI org itself:
+      SQLModel over SQLAlchemy 2.0, Postgres, Alembic migrations, Docker Compose, and
+      pytest fixtures that run against a real database rather than mocks. Borrow the
+      SQLModel model/schema unification (one class serving table + API contract), the
+      Alembic setup, and the compose service wiring for a DB that is healthy before the app
+      boots.
+    whatToAvoid: >-
+      NOTE the URL: the repo moved from tiangolo/ to fastapi/ — the old path only survives as
+      a redirect and should not be hardcoded. Postgres-only; there is no MySQL or SQLite
+      switch, so other engines mean real edits. It is a full-stack template (React frontend,
+      Traefik, auth) — the DB layer must be extracted deliberately or a db-* layer pulls in
+      an entire product.
+    proposedLayerIds:
+      - db-postgres-sqlmodel
+      - migrations-alembic-python
+      - db-postgres-docker-compose
+
+  - name: minimal-fastapi-postgres-template
+    url: https://github.com/rafsaf/minimal-fastapi-postgres-template
+    stack: python
+    stars: 572
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-01"
+    complexity: simple
+    whatToBorrow: >-
+      The readable, strip-down counterpart to the official FastAPI template — 52 files total,
+      which is small enough to audit line by line before vendoring. Verified layout:
+      app/core/database_session.py (async engine + session factory), app/core/config.py
+      (pydantic-settings, no hardcoded DSNs), alembic.ini, alembic/env.py wired for async, and
+      a real initial revision in alembic/versions/. This is the cleanest async SQLAlchemy 2.0
+      + asyncpg session-management example to borrow wholesale.
+    whatToAvoid: >-
+      Single-maintainer project with modest stars — vendor the patterns, do not depend on it as
+      an upstream. Postgres/asyncpg only. It bundles a JWT auth opinion (app/auth/) that a pure
+      db layer should leave behind.
+    proposedLayerIds:
+      - db-postgres-sqlalchemy-async
+      - migrations-alembic-python
+      - db-session-dependency-fastapi
+
+  - name: alembic
+    url: https://github.com/sqlalchemy/alembic
+    stack: python
+    stars: 4263
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-16"
+    complexity: standard
+    whatToBorrow: >-
+      The migration engine both Python templates above depend on, from the SQLAlchemy org.
+      Borrow its env.py templates (it ships generic, async and multidb variants — the multidb
+      template is directly relevant to a multi-database Groundplan layer), the script.py.mako
+      revision template, and the branch/merge model for migration history in teams.
+    whatToAvoid: >-
+      Autogenerate detects far less than users assume — column type changes, renames and
+      server defaults routinely need hand-editing, so a generated layer should never present
+      autogenerate as authoritative. Tied to SQLAlchemy; useless for a non-SQLAlchemy stack,
+      where dbmate or Atlas is the better fit.
+    proposedLayerIds:
+      - migrations-alembic-python
+      - migrations-alembic-multidb
+
+  - name: CleanArchitecture
+    url: https://github.com/jasontaylordev/CleanArchitecture
+    stack: dotnet
+    stars: 20343
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    complexity: enterprise
+    whatToBorrow: >-
+      A working model of parameterised database selection, which is precisely Groundplan's problem.
+      Verified from .template.config/template.json: a Database choice symbol with values
+      postgresql, sqlite, sqlserver — read this file to see how dotnet new expresses a DB
+      switch and how the conditional source blocks are organised. Also borrow
+      src/Infrastructure/Data/ApplicationDbContext.cs, the IEntityTypeConfiguration split under
+      Data/Configurations/, and especially Data/Interceptors/AuditableEntityInterceptor.cs and
+      DispatchDomainEventsInterceptor.cs — SaveChanges interceptors are the cleanest way to add
+      audit columns and domain events without polluting entities.
+    whatToAvoid: >-
+      CORRECTION to a common secondary-source claim: the default Database value is sqlite, not
+      sqlserver, and there is NO mysql option — do not plan db-mysql-efcore from this source.
+      Genuinely heavy: CQRS, MediatR, layered projects and an Angular/React client are all
+      opinions bundled with the persistence code. Wrong starting point for a small service, and
+      the DB layer needs real surgery to extract.
+    proposedLayerIds:
+      - db-sqlserver-efcore
+      - db-postgres-efcore
+      - db-sqlite-efcore
+      - orm-efcore-interceptors-audit
+
+  - name: Dapper
+    url: https://github.com/DapperLib/Dapper
+    stack: dotnet
+    stars: 18353
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-05-16"
+    complexity: simple
+    whatToBorrow: >-
+      The .NET micro-ORM tier: extension methods over IDbConnection, so it works against SQL
+      Server, Postgres, MySQL and SQLite with the same code and no model layer. Borrow the
+      Query/Execute call shape, the multi-mapping (splitOn) pattern for joins, and its
+      connection-per-operation model for a lightweight db layer that pairs with dbmate or
+      Flyway for schema.
+    whatToAvoid: >-
+      LICENSE NOTE worth recording: the license lives at License.txt (capital-L, lowercase-c —
+      it is easy to conclude the repo is unlicensed if you only probe LICENSE), it is Apache-2.0,
+      and it carries an explicit Dapper LOGO trademark restriction — the code is free to adapt,
+      the logo is not, so never emit Dapper branding into a generated project. No migrations, no
+      schema management, no change tracking — pair it with a migration layer or users hand-roll
+      SQL forever.
+    proposedLayerIds:
+      - db-sqlserver-dapper
+      - db-postgres-dapper
+      - orm-micro-dapper
+
+  - name: sqlc
+    url: https://github.com/sqlc-dev/sqlc
+    stack: go
+    stars: 18029
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-16"
+    complexity: standard
+    whatToBorrow: >-
+      The SQL-first inversion of the ORM: you write .sql, it generates type-safe Go. Borrow the
+      sqlc.yaml config shape (engine + sql_package selection — pgx/v5 vs database/sql is a
+      single field, which maps cleanly onto a Groundplan layer option), the query.sql / schema.sql
+      file convention, and the generated Querier interface, which gives handlers a mockable
+      seam without a repository framework.
+    whatToAvoid: >-
+      Codegen must be re-run on every schema change or the Go code silently diverges from the
+      database — a generated project needs that wired into its build/CI or it rots. Postgres
+      support is materially ahead of MySQL and SQLite. Dynamic/conditional queries are painful;
+      teams end up hand-writing those alongside, so do not present sqlc as a total solution.
+    proposedLayerIds:
+      - db-postgres-sqlc
+      - db-mysql-sqlc
+      - db-sqlite-sqlc
+      - db-postgres-pgx
+
+  - name: gorm
+    url: https://github.com/go-gorm/gorm
+    stack: go
+    stars: 39872
+    spdx: MIT
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-06-25"
+    complexity: standard
+    whatToBorrow: >-
+      The full-ORM counterweight to sqlc for Go, and the broader dialect set: separate driver
+      packages for postgres, mysql, sqlite and sqlserver behind one gorm.Open call. Borrow the
+      gorm.Model embedded struct (ID/CreatedAt/UpdatedAt/DeletedAt), the struct-tag mapping
+      conventions, and the Session/context and connection-pool configuration.
+    whatToAvoid: >-
+      AutoMigrate is not a migration system — it never drops or safely alters columns, so a
+      generated layer must pair GORM with golang-migrate, goose or Atlas for anything real.
+      Reflection-heavy and measurably slower than sqlc/pgx on hot paths, and its chainable API
+      makes it easy to write N+1 queries without noticing. Offer it as the ergonomic choice,
+      not the performance one.
+    proposedLayerIds:
+      - db-postgres-gorm
+      - db-mysql-gorm
+      - db-sqlite-gorm
+      - db-sqlserver-gorm
+
+  - name: atlas
+    url: https://github.com/ariga/atlas
+    stack: go
+    stars: 8586
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-06-25"
+    complexity: professional
+    whatToBorrow: >-
+      The language-agnostic, declarative migration layer: you declare desired schema (HCL or
+      plain SQL) and Atlas plans the diff, which suits a scaffolding tool better than
+      per-ORM migration CLIs. Borrow the atlas.hcl env/config structure, the versioned vs
+      declarative workflow split, the migration lint rules that catch destructive changes in
+      CI, and its ORM-provider integrations that let it drive migrations for GORM, Prisma and
+      SQLAlchemy schemas alike.
+    whatToAvoid: >-
+      LICENSE TRAP — check this carefully per directory. The ariga/atlas repo is Apache-2.0,
+      but Atlas is open-core: Atlas Pro/Cloud features (drift detection, schema registry,
+      some linting) are commercial and gated behind login. Keep generated layers on the
+      Apache-2.0 CLI surface only, and never scaffold a workflow that silently requires an
+      Atlas Cloud account. HCL is a second schema language for the team to learn.
+    proposedLayerIds:
+      - migrations-atlas-declarative
+      - migrations-atlas-versioned
+      - migrations-atlas-ci-lint
+
+  - name: supabase
+    url: https://github.com/supabase/supabase
+    stack: postgres
+    stars: 106527
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    complexity: enterprise
+    whatToBorrow: >-
+      A complete, self-hostable Postgres platform, and a strong reference for composable
+      infrastructure. Verified under docker/: docker-compose.yml plus overlay files
+      docker-compose.pg15.yml, docker-compose.pg17.yml, docker-compose.s3.yml,
+      docker-compose.rustfs.yml, docker-compose.caddy.yml, docker-compose.nginx.yml,
+      docker-compose.envoy.yml and docker-compose.logs.yml, with .env.example, setup.sh,
+      run.sh and reset.sh. That overlay pattern
+      — one base compose file plus opt-in overlays for PG version, storage backend and proxy —
+      is directly transferable to how Groundplan should compose db layers. Also borrow the RLS
+      policy examples as the model for row-level multi-tenancy.
+    whatToAvoid: >-
+      The repo is Apache-2.0 at the top level but is a monorepo of many services with their own
+      licenses — verify the specific subdirectory before copying any file, do not rely on the
+      root LICENSE. Self-hosting the full stack (Postgres, GoTrue, PostgREST, Realtime,
+      Storage, Studio, Kong) is a serious operational commitment and wildly oversized as a
+      default db layer. Managed Supabase is a vendor dependency; keep the Postgres connection
+      layer swappable so users are not stranded.
+    proposedLayerIds:
+      - db-postgres-supabase
+      - db-supabase-selfhost-docker
+      - db-postgres-rls-multitenant
+
+droppedCandidates:
+  - "liquibase/liquibase — EXCLUDED ON LICENSE. LICENSE.txt reads 'Functional Source License, Version 1.1, ALv2 Future License'. FSL is source-available, not open source; it cannot be vendored into generated repos. 5563 stars, actively maintained (2026-07-17) — healthy project, wrong license. Use Flyway or Atlas instead."
+  - "redis/redis (server) — EXCLUDED ON LICENSE. Server relicensed away from BSD to AGPL-3.0/RSALv2. Depend on the Docker image, never copy source. Redis coverage comes from the MIT-licensed ioredis client instead."
+  - "mongodb/mongo (server) — EXCLUDED ON LICENSE (SSPL). MongoDB coverage comes from the MIT Mongoose driver and Prisma's mongodb example instead."
+  - "tursodatabase/nextjs-turso-starter — dropped on weakness, not license. Only 14 stars and last pushed 2025-12-06; too thin to build a layer on. Turso coverage comes from drizzle-orm's libsql driver and prisma-examples/databases/turso."
+  - "t3-oss/create-t3-app — MIT, 29048 stars, but last pushed 2025-12-13 (~7 months). Not stale by the 18-month rule, yet visibly slowing, and its DB story is a thin wrapper over Prisma/Drizzle already covered above."
+  - "typeorm/typeorm — MIT, 36600 stars, pushed 2026-07-17. Cut for redundancy only: it is already represented through brocoders/nestjs-boilerplate, and its long-running maintenance/velocity concerns make it a poor primary recommendation despite the widest driver matrix (incl. Oracle)."
+  - "mikro-orm/mikro-orm — MIT, 9131 stars, pushed 2026-07-17. Strong runner-up (real unit-of-work/identity-map, SQL + Mongo). Cut to keep the TypeScript ORM tier from crowding out other stacks; revisit if a db-mongodb-sql-unified layer is wanted."
+  - "amacneil/dbmate — MIT, 7003 stars, pushed 2026-07-16. Strong runner-up for the simple migration tier (plain SQL, no runtime, PG/MySQL/SQLite/ClickHouse). Cut because Atlas and Alembic already cover migrations; add it if a zero-dependency SQL migration layer is needed."
+  - "flyway/flyway — Apache-2.0 verified from LICENSE.md, 9926 stars, pushed 2026-07-09. Cut for scope: JVM-centric, and Redgate has been tightening the commercial tiers around the OSS core. Atlas covers the same need without the JVM."
+  - "dotnet/efcore — MIT, 14741 stars, pushed 2026-07-18. The library itself; cut in favour of jasontaylordev/CleanArchitecture, which shows EF Core in an actually-adoptable template with a working DB switch."
+  - "Automattic/mongoose — MIT, 27479 stars, pushed 2026-07-18. Cut only because brocoders/nestjs-boilerplate already ships Mongoose inside a swappable persistence port. Promote it if a standalone MongoDB layer is required."
+  - "neondatabase/serverless (MIT, 539 stars) and tursodatabase/libsql (MIT, 16973 stars) — both verified healthy. Cut as standalone entries because the serverless tier is better expressed through drizzle-orm's neon-http/neon-serverless/libsql drivers than as separate template sources."
+  - "planetscale/database-js — Apache-2.0, 1198 stars, pushed 2026-06-30. Same reasoning: covered by drizzle-orm's planetscale-serverless driver."
+  - "knex/knex, sequelize/sequelize, jackc/pgx, golang-migrate/migrate, pressly/goose, WiseLibs/better-sqlite3, ardalis/CleanArchitecture, epicweb-dev/epic-stack, benavlabs/FastAPI-boilerplate, NarHakobyan/awesome-nest-boilerplate — all verified live and permissively licensed, all cut for redundancy against a stronger entry in the same slot. Available as substitutes if any entry above is rejected."
+
+notes: >-
+  Coverage check against the requested matrix. Postgres: drizzle, prisma-examples, kysely,
+  brocoders, both FastAPI templates, CleanArchitecture, sqlc, gorm, supabase. MySQL/MariaDB:
+  drizzle, prisma-examples, kysely, sqlc, gorm. SQL Server: prisma-examples
+  (databases/sql-server), CleanArchitecture (verified template.json choice), Dapper, gorm,
+  kysely (verified src/dialect/mssql — the only TypeScript SQL Server option here).
+  SQLite: drizzle, kysely, CleanArchitecture (the verified default), sqlc, gorm.
+  MongoDB: brocoders (Mongoose), prisma-examples (databases/mongodb). Redis: ioredis.
+  Serverless tier: drizzle drivers (neon-http, neon-serverless, planetscale-serverless, d1,
+  libsql, supabase, vercel-postgres) plus cloudflare/templates for D1 and
+  prisma-examples/databases/turso. ORMs: Prisma, Drizzle, TypeORM (via brocoders), Kysely,
+  SQLAlchemy, SQLModel, EF Core, Dapper, GORM, sqlc — MikroORM is the one requested ORM not in
+  the final list, noted in droppedCandidates. Migrations: Alembic, Atlas, plus Flyway and
+  dbmate verified and held in reserve.
+
+  Two requested tools are license-blocked and cannot be vendored at all: Liquibase (FSL-1.1)
+  and the Redis and MongoDB servers (AGPL/RSALv2 and SSPL). Atlas needs the most care of the
+  vendorable set — the CLI is Apache-2.0 but the product is open-core, so layers must stay on
+  the OSS surface.
+
+  Shared layer ids — two ids are intentionally claimed by more than one entry, and downstream
+  must not treat them as duplicates to dedupe blindly. `migrations-alembic-python` appears
+  under three entries; the OWNER is the alembic entry (the engine and its env.py/script.py.mako
+  templates), while full-stack-fastapi-template and minimal-fastapi-postgres-template are two
+  alternative wirings of it — build the layer from alembic and take the wiring from whichever
+  Python entry matches the target complexity tier. `db-d1-drizzle` appears under both
+  drizzle-orm and cloudflare-templates because it is genuinely a composition of the two:
+  wrangler/binding config and migrations convention from cloudflare/templates, driver and
+  schema from drizzle-orm's d1 module. Every other id is claimed exactly once.
+
+  Complexity ladder: simple = kysely, minimal-fastapi-postgres-template, Dapper, ioredis;
+  standard = drizzle-orm, prisma-examples, cloudflare-templates, alembic, sqlc, gorm;
+  professional = brocoders/nestjs-boilerplate, full-stack-fastapi-template, atlas;
+  enterprise = jasontaylordev/CleanArchitecture, supabase.
+
+  Two corrections made by reading primary sources rather than trusting secondary write-ups:
+  the CleanArchitecture template defaults to sqlite (not sqlserver) and offers no mysql
+  option, and Cloudflare's D1 templates do not use Drizzle. Both would have produced broken
+  layer definitions downstream.