74 lines
3.5 KiB
Plaintext
74 lines
3.5 KiB
Plaintext
---
|
|
title: Database
|
|
label: Overview
|
|
order: 10
|
|
keywords: database, mongodb, postgres, documentation, Content Management System, cms, headless, typescript, node, react, express
|
|
desc: With Payload, you bring your own database and own your data. You have full control.
|
|
---
|
|
|
|
Payload interacts with your database via the database adapter that you choose. Right now, Payload officially supports two database adapters:
|
|
|
|
1. [MongoDB](/docs/database/mongodb) w/ [Mongoose](https://mongoosejs.com/)
|
|
1. [Postgres](/docs/database/postgres) w/ [Drizzle](https://drizzle.team/)
|
|
|
|
We will be adding support for SQLite and MySQL in the near future using Drizzle ORM.
|
|
|
|
To use a specific database adapter, you need to install it and configure it according to its own specifications. Visit the documentation for your applicable database adapter to learn more.
|
|
|
|
## Selecting a database
|
|
|
|
There are several factors to consider when choosing which database technology and hosting option is right for your project and workload. Payload can theoretically support any database, but it's up to you to decide which database to use.
|
|
|
|
#### When to use MongoDB
|
|
|
|
If your project has a lot of dynamic fields, and you are comfortable with allowing Payload to enforce data integrity across your documents, MongoDB is a great choice. With it, your Payload documents are stored as _one_ document in your database—no matter if you have localization enabled, how many block or array fields you have, etc. This means that the shape of your data in your database will very closely reflect your field schema, and there is minimal complexity involved in storing or retrieving your data.
|
|
|
|
You should prefer MongoDB if:
|
|
|
|
- You prefer simplicity within your database
|
|
- You don't want to deal with keeping production / staging databases in sync via [DDL changes](https://en.wikipedia.org/wiki/Data_definition_language)
|
|
- Most (or everything) in your project is localized
|
|
- You leverage a lot of array fields, block fields, or `hasMany` select fields and similar
|
|
|
|
#### When to use a relational DB
|
|
|
|
Many projects might call for more rigid database architecture where the shape of your data is strongly enforced at the database level. For example, if you know the shape of your data and it's relatively "flat", and you don't anticipate it to change often, your workload might suit relational databases like Postgres very well.
|
|
|
|
You should prefer a relational DB like Postgres if:
|
|
|
|
- You are comfortable with migration workflows
|
|
- You require enforced data consistency at the database level
|
|
- You have a lot of relationships between collections and require relationships to be enforced
|
|
|
|
#### Differences in Payload features
|
|
|
|
It's important to note that almost everything Payload does is available in all of our officially supported database adapters, including localization, arrays, blocks, etc.
|
|
|
|
The only thing that is not supported in Postgres yet is the [Point field](/docs/fields/point), but that should be added soon.
|
|
|
|
It's up to you to choose which database you would like to use.
|
|
|
|
## Configuration
|
|
|
|
To configure the database for your Payload application, an adapter can be assigned to `config.db`. This property is required within your Payload config.
|
|
|
|
Here's an example:
|
|
|
|
```ts
|
|
import { postgresAdapter } from '@payloadcms/db-postgres'
|
|
|
|
export default buildConfig({
|
|
// Your config goes here
|
|
collections: [
|
|
// Collections go here
|
|
],
|
|
// Here is where you pass your database adapter
|
|
// and the adapter will require options specific to itself
|
|
db: postgresAdapter({
|
|
pool: {
|
|
connectionString: process.env.DATABASE_URI,
|
|
},
|
|
}),
|
|
})
|
|
```
|