2024-09-16 13:02:08 -04:00
import fs from 'fs'
import path from 'node:path'
import { fileURLToPath } from 'node:url'
const filename = fileURLToPath ( import . meta . url )
const dirname = path . dirname ( filename )
2025-12-19 12:00:08 -08:00
// Runs on port 27018 to avoid conflicts with locally installed MongoDB
2025-10-06 16:48:02 -04:00
const mongooseAdapterArgs = `
2024-11-12 14:42:25 -05:00
ensureIndexes: true,
2024-08-19 17:31:36 -04:00
url:
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
process.env.MONGODB_URL || process.env.DATABASE_URL ||
2025-12-19 12:00:08 -08:00
'mongodb://payload:payload@localhost:27018/payload?authSource=admin&directConnection=true&replicaSet=rs0',
2025-10-06 16:48:02 -04:00
`
2026-01-07 14:25:15 -08:00
export const defaultPostgresUrl = 'postgres://payload:payload@127.0.0.1:5433/payload'
2025-10-06 16:48:02 -04:00
export const allDatabaseAdapters = {
mongodb : `
import { mongooseAdapter } from '@payloadcms/db-mongodb'
export const databaseAdapter = mongooseAdapter({
${ mongooseAdapterArgs }
}) ` ,
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
// mongodb-atlas uses Docker-based MongoDB Atlas Local (all-in-one with search)
// Start with: pnpm docker:mongodb-atlas:start
2025-12-19 12:00:08 -08:00
// Runs on port 27019 to avoid conflicts with mongodb
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
'mongodb-atlas' : `
import { mongooseAdapter } from '@payloadcms/db-mongodb'
export const databaseAdapter = mongooseAdapter({
ensureIndexes: true,
url:
process.env.MONGODB_ATLAS_URL || process.env.DATABASE_URL ||
2025-12-19 12:00:08 -08:00
'mongodb://localhost:27019/payload?directConnection=true&replicaSet=mongodb-atlas-local',
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
}) ` ,
2025-10-06 16:48:02 -04:00
cosmosdb : `
import { mongooseAdapter, compatibilityOptions } from '@payloadcms/db-mongodb'
export const databaseAdapter = mongooseAdapter({
...compatibilityOptions.cosmosdb,
${ mongooseAdapterArgs }
}) ` ,
documentdb : `
import { mongooseAdapter, compatibilityOptions } from '@payloadcms/db-mongodb'
export const databaseAdapter = mongooseAdapter({
...compatibilityOptions.documentdb,
${ mongooseAdapterArgs }
2024-08-19 17:31:36 -04:00
}) ` ,
fix(db-mongodb): improve compatibility with Firestore database (#12763)
### What?
Adds four more arguments to the `mongooseAdapter`:
```typescript
useJoinAggregations?: boolean /* The big one */
useAlternativeDropDatabase?: boolean
useBigIntForNumberIDs?: boolean
usePipelineInSortLookup?: boolean
```
Also export a new `compatabilityOptions` object from
`@payloadcms/db-mongodb` where each key is a mongo-compatible database
and the value is the recommended `mongooseAdapter` settings for
compatability.
### Why?
When using firestore and visiting
`/admin/collections/media/payload-folders`, we get:
```
MongoServerError: invalid field(s) in lookup: [let, pipeline], only lookup(from, localField, foreignField, as) is supported
```
Firestore doesn't support the full MongoDB aggregation API used by
Payload which gets used when building aggregations for populating join
fields.
There are several other compatability issues with Firestore:
- The invalid `pipeline` property is used in the `$lookup` aggregation
in `buildSortParams`
- Firestore only supports number IDs of type `Long`, but Mongoose
converts custom ID fields of type number to `Double`
- Firestore does not support the `dropDatabase` command
- Firestore does not support the `createIndex` command (not addressed in
this PR)
### How?
```typescript
useJoinAggregations?: boolean /* The big one */
```
When this is `false` we skip the `buildJoinAggregation()` pipeline and resolve the join fields through multiple queries. This can potentially be used with AWS DocumentDB and Azure Cosmos DB to support join fields, but I have not tested with either of these databases.
```typescript
useAlternativeDropDatabase?: boolean
```
When `true`, monkey-patch (replace) the `dropDatabase` function so that
it calls `collection.deleteMany({})` on every collection instead of
sending a single `dropDatabase` command to the database
```typescript
useBigIntForNumberIDs?: boolean
```
When `true`, use `mongoose.Schema.Types.BigInt` for custom ID fields of type `number` which converts to a firestore `Long` behind the scenes
```typescript
usePipelineInSortLookup?: boolean
```
When `false`, modify the sortAggregation pipeline in `buildSortParams()` so that we don't use the `pipeline` property in the `$lookup` aggregation. Results in slightly worse performance when sorting by relationship properties.
### Limitations
This PR does not add support for transactions or creating indexes in firestore.
### Fixes
Fixed a bug (and added a test) where you weren't able to sort by multiple properties on a relationship field.
### Future work
1. Firestore supports simple `$lookup` aggregations but other databases might not. Could add a `useSortAggregations` property which can be used to disable aggregations in sorting.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Sasha <64744993+r1tsuu@users.noreply.github.com>
2025-07-17 01:02:43 +05:45
firestore : `
2025-08-21 00:31:19 +08:00
import { mongooseAdapter, compatibilityOptions } from '@payloadcms/db-mongodb'
fix(db-mongodb): improve compatibility with Firestore database (#12763)
### What?
Adds four more arguments to the `mongooseAdapter`:
```typescript
useJoinAggregations?: boolean /* The big one */
useAlternativeDropDatabase?: boolean
useBigIntForNumberIDs?: boolean
usePipelineInSortLookup?: boolean
```
Also export a new `compatabilityOptions` object from
`@payloadcms/db-mongodb` where each key is a mongo-compatible database
and the value is the recommended `mongooseAdapter` settings for
compatability.
### Why?
When using firestore and visiting
`/admin/collections/media/payload-folders`, we get:
```
MongoServerError: invalid field(s) in lookup: [let, pipeline], only lookup(from, localField, foreignField, as) is supported
```
Firestore doesn't support the full MongoDB aggregation API used by
Payload which gets used when building aggregations for populating join
fields.
There are several other compatability issues with Firestore:
- The invalid `pipeline` property is used in the `$lookup` aggregation
in `buildSortParams`
- Firestore only supports number IDs of type `Long`, but Mongoose
converts custom ID fields of type number to `Double`
- Firestore does not support the `dropDatabase` command
- Firestore does not support the `createIndex` command (not addressed in
this PR)
### How?
```typescript
useJoinAggregations?: boolean /* The big one */
```
When this is `false` we skip the `buildJoinAggregation()` pipeline and resolve the join fields through multiple queries. This can potentially be used with AWS DocumentDB and Azure Cosmos DB to support join fields, but I have not tested with either of these databases.
```typescript
useAlternativeDropDatabase?: boolean
```
When `true`, monkey-patch (replace) the `dropDatabase` function so that
it calls `collection.deleteMany({})` on every collection instead of
sending a single `dropDatabase` command to the database
```typescript
useBigIntForNumberIDs?: boolean
```
When `true`, use `mongoose.Schema.Types.BigInt` for custom ID fields of type `number` which converts to a firestore `Long` behind the scenes
```typescript
usePipelineInSortLookup?: boolean
```
When `false`, modify the sortAggregation pipeline in `buildSortParams()` so that we don't use the `pipeline` property in the `$lookup` aggregation. Results in slightly worse performance when sorting by relationship properties.
### Limitations
This PR does not add support for transactions or creating indexes in firestore.
### Fixes
Fixed a bug (and added a test) where you weren't able to sort by multiple properties on a relationship field.
### Future work
1. Firestore supports simple `$lookup` aggregations but other databases might not. Could add a `useSortAggregations` property which can be used to disable aggregations in sorting.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Sasha <64744993+r1tsuu@users.noreply.github.com>
2025-07-17 01:02:43 +05:45
export const databaseAdapter = mongooseAdapter({
2025-08-21 00:31:19 +08:00
...compatibilityOptions.firestore,
2025-10-06 16:48:02 -04:00
${ mongooseAdapterArgs }
fix(db-mongodb): improve compatibility with Firestore database (#12763)
### What?
Adds four more arguments to the `mongooseAdapter`:
```typescript
useJoinAggregations?: boolean /* The big one */
useAlternativeDropDatabase?: boolean
useBigIntForNumberIDs?: boolean
usePipelineInSortLookup?: boolean
```
Also export a new `compatabilityOptions` object from
`@payloadcms/db-mongodb` where each key is a mongo-compatible database
and the value is the recommended `mongooseAdapter` settings for
compatability.
### Why?
When using firestore and visiting
`/admin/collections/media/payload-folders`, we get:
```
MongoServerError: invalid field(s) in lookup: [let, pipeline], only lookup(from, localField, foreignField, as) is supported
```
Firestore doesn't support the full MongoDB aggregation API used by
Payload which gets used when building aggregations for populating join
fields.
There are several other compatability issues with Firestore:
- The invalid `pipeline` property is used in the `$lookup` aggregation
in `buildSortParams`
- Firestore only supports number IDs of type `Long`, but Mongoose
converts custom ID fields of type number to `Double`
- Firestore does not support the `dropDatabase` command
- Firestore does not support the `createIndex` command (not addressed in
this PR)
### How?
```typescript
useJoinAggregations?: boolean /* The big one */
```
When this is `false` we skip the `buildJoinAggregation()` pipeline and resolve the join fields through multiple queries. This can potentially be used with AWS DocumentDB and Azure Cosmos DB to support join fields, but I have not tested with either of these databases.
```typescript
useAlternativeDropDatabase?: boolean
```
When `true`, monkey-patch (replace) the `dropDatabase` function so that
it calls `collection.deleteMany({})` on every collection instead of
sending a single `dropDatabase` command to the database
```typescript
useBigIntForNumberIDs?: boolean
```
When `true`, use `mongoose.Schema.Types.BigInt` for custom ID fields of type `number` which converts to a firestore `Long` behind the scenes
```typescript
usePipelineInSortLookup?: boolean
```
When `false`, modify the sortAggregation pipeline in `buildSortParams()` so that we don't use the `pipeline` property in the `$lookup` aggregation. Results in slightly worse performance when sorting by relationship properties.
### Limitations
This PR does not add support for transactions or creating indexes in firestore.
### Fixes
Fixed a bug (and added a test) where you weren't able to sort by multiple properties on a relationship field.
### Future work
1. Firestore supports simple `$lookup` aggregations but other databases might not. Could add a `useSortAggregations` property which can be used to disable aggregations in sorting.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Sasha <64744993+r1tsuu@users.noreply.github.com>
2025-07-17 01:02:43 +05:45
// The following options prevent some tests from failing.
// More work needed to get tests succeeding without these options.
ensureIndexes: true,
disableIndexHints: false,
useAlternativeDropDatabase: false,
}) ` ,
2024-08-19 17:31:36 -04:00
postgres : `
import { postgresAdapter } from '@payloadcms/db-postgres'
export const databaseAdapter = postgresAdapter({
pool: {
2026-01-07 14:25:15 -08:00
connectionString: process.env.POSTGRES_URL || process.env.DATABASE_URL || ' ${ defaultPostgresUrl } ',
2024-08-19 17:31:36 -04:00
},
}) ` ,
'postgres-custom-schema' : `
import { postgresAdapter } from '@payloadcms/db-postgres'
export const databaseAdapter = postgresAdapter({
pool: {
2026-01-07 14:25:15 -08:00
connectionString: process.env.POSTGRES_URL || process.env.DATABASE_URL || ' ${ defaultPostgresUrl } ',
2024-08-19 17:31:36 -04:00
},
schemaName: 'custom',
}) ` ,
'postgres-uuid' : `
import { postgresAdapter } from '@payloadcms/db-postgres'
export const databaseAdapter = postgresAdapter({
idType: 'uuid',
pool: {
2026-01-07 14:25:15 -08:00
connectionString: process.env.POSTGRES_URL || process.env.DATABASE_URL || ' ${ defaultPostgresUrl } ',
2024-08-19 17:31:36 -04:00
},
}) ` ,
2025-06-09 22:09:52 +03:00
'postgres-read-replica' : `
import { postgresAdapter } from '@payloadcms/db-postgres'
export const databaseAdapter = postgresAdapter({
pool: {
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
connectionString: process.env.POSTGRES_URL || process.env.DATABASE_URL,
2025-06-09 22:09:52 +03:00
},
readReplicas: [process.env.POSTGRES_REPLICA_URL],
})
2026-01-16 20:19:25 +00:00
` ,
'content-api' : `
import { contentAPIAdapter } from '@payloadcms/figma'
export const databaseAdapter = contentAPIAdapter({
auth: {
mode: 'devJwt',
},
url: process.env.CONTENT_API_URL || 'http://localhost:8080',
contentSystemId: process.env.CONTENT_SYSTEM_ID || '00000000-0000-4000-8000-000000000001',
})
2025-06-09 22:09:52 +03:00
` ,
'vercel-postgres-read-replica' : `
import { vercelPostgresAdapter } from '@payloadcms/db-vercel-postgres'
export const databaseAdapter = vercelPostgresAdapter({
pool: {
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
connectionString: process.env.POSTGRES_URL || process.env.DATABASE_URL,
2025-06-09 22:09:52 +03:00
},
readReplicas: [process.env.POSTGRES_REPLICA_URL],
})
` ,
2024-08-19 17:31:36 -04:00
sqlite : `
import { sqliteAdapter } from '@payloadcms/db-sqlite'
export const databaseAdapter = sqliteAdapter({
client: {
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
url: process.env.SQLITE_URL || process.env.DATABASE_URL || 'file:./payload.db',
2024-08-19 17:31:36 -04:00
},
2024-12-20 22:13:28 +02:00
autoIncrement: true
2024-08-19 17:31:36 -04:00
}) ` ,
2024-12-19 05:44:04 +02:00
'sqlite-uuid' : `
import { sqliteAdapter } from '@payloadcms/db-sqlite'
export const databaseAdapter = sqliteAdapter({
idType: 'uuid',
client: {
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
url: process.env.SQLITE_URL || process.env.DATABASE_URL || 'file:./payload.db',
2026-01-13 13:51:47 -05:00
}
2024-12-19 05:44:04 +02:00
}) ` ,
2024-08-19 17:31:36 -04:00
supabase : `
import { postgresAdapter } from '@payloadcms/db-postgres'
export const databaseAdapter = postgresAdapter({
pool: {
connectionString:
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
process.env.POSTGRES_URL || process.env.DATABASE_URL || 'postgresql://postgres:postgres@127.0.0.1:54322/postgres',
2024-08-19 17:31:36 -04:00
},
}) ` ,
2025-09-29 23:58:18 +03:00
d1 : `
import { sqliteD1Adapter } from '@payloadcms/db-d1-sqlite'
export const databaseAdapter = sqliteD1Adapter({ binding: global.d1 })
` ,
2024-08-19 17:31:36 -04:00
}
2024-09-16 13:02:08 -04:00
/**
* Write to databaseAdapter.ts
*/
test: improve database test setup (#14982)
This PR brings over most of the test suite improvements I made
[here](https://github.com/payloadcms/enterprise-plugins/pull/249) to our
payload monorepo.
- Replaces mongodb-memory-server with an actual mongo db using the
mongodb-community-server docker image. This unblocks the vitest
migration PR (https://github.com/payloadcms/payload/pull/14337).
Currently, debugging does not work in that PR - this is due to the
global setup script that has to start the mongo memory db.
- Just like postgres, all mongodb databases now support vector search.
mongodb-atlas-local supports it natively, and for
mongodb-community-server, our docker compose script installs `mongot`,
which unlocks support for vector search. This means we could add [vector
storage/search tests similar to the ones we have for
postgres](https://github.com/payloadcms/payload/blob/main/test/database/postgres-vector.int.spec.ts)
- Int tests now run against both mongodb adapters: mongodb
(mongodb-community-server) and mongodb-atlas (mongodb-atlas-local)
- Adds docker scripts for mongodb, mongodb-atlas, and postgres,
documented in README.md. Updates default db adapter URLs to
automatically pick up databases started by those scripts. This makes it
easier for people cloning the repo to get started with consistent
databases matching CI - no complicated manual installation steps
- Simplified db setup handling locally in CI. In CI, everything is
scoped to `.github/actions/start-database/action.yml`. Locally,
everything is scoped to `test/helpers/db`. Each database adapter now
shares the same username, password and db name
- Use consistent db connection string env variables, all ending with
_URL
- Updates the CONTRIBUTING.md with up-to-date information and adds a new
database section. We now recommend everyone to use those docker scripts
2025-12-19 07:07:16 -08:00
export function generateDatabaseAdapter ( dbAdapter : keyof typeof allDatabaseAdapters ) {
2024-09-16 13:02:08 -04:00
const databaseAdapter = allDatabaseAdapters [ dbAdapter ]
if ( ! databaseAdapter ) {
throw new Error ( ` Unknown database adapter: ${ dbAdapter } ` )
}
fs . writeFileSync (
path . resolve ( dirname , 'databaseAdapter.js' ) ,
`
// DO NOT MODIFY. This file is automatically generated by the test suite.
${ databaseAdapter }
` ,
)
console . log ( 'Wrote' , dbAdapter , 'db adapter' )
return databaseAdapter
2024-08-19 17:31:36 -04:00
}
2026-01-13 03:52:28 +02:00
export type DatabaseAdapterType = keyof typeof allDatabaseAdapters
export const getCurrentDatabaseAdapter = ( ) : DatabaseAdapterType = > {
const dbAdapter = process . env . PAYLOAD_DATABASE as DatabaseAdapterType | undefined
if ( dbAdapter && Object . keys ( allDatabaseAdapters ) . includes ( dbAdapter ) ) {
return dbAdapter
}
return 'mongodb'
}
