# Adapters

> Connect Ridu to databases and object-storage providers without changing CMS behavior.

Canonical URL: https://riducms.com/docs/adapters/

Adapters connect Ridu to infrastructure that the framework already knows how to use. A database
adapter stores documents; an object-storage adapter stores upload bytes. An application normally
selects one implementation for each required runtime port.

Plugins are different: they add CMS or admin behavior such as rich text, GraphQL, fields, hooks, or
views. Multiple plugins can coexist in `Config.Plugins`; adapters do not appear there.

| Need                                                 | Use                       | Official implementation                                                              |
| ---------------------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------ |
| Store content and framework state                    | `store.Store` adapter     | [PostgreSQL](https://riducms.com/docs/postgres/), [SQLite](https://riducms.com/docs/sqlite/), or [MongoDB](https://riducms.com/docs/mongodb/) |
| Store upload bytes locally                           | `storage.Backend` adapter | [Object storage](https://riducms.com/docs/storage/#local-storage)                                       |
| Store upload bytes in S3 or an S3-compatible service | `storage.Backend` adapter | [Object storage](https://riducms.com/docs/storage/#s3-storage)                                          |
| Add rich-text fields and their editor                | Plugin                    | [Rich text](https://riducms.com/docs/rich-text/)                                                        |
| Add a GraphQL transport                              | Plugin                    | [GraphQL](https://riducms.com/docs/graphql/)                                                            |

Runtime adapters are created lazily with `ridu.WithStore` and `ridu.WithUploadStorage`. This keeps
database URLs, cloud credentials, open clients, and network access out of schema generation and the
canonical manifest.

PostgreSQL is the general networked and multi-replica store. SQLite is official for a database file
on one application host and small or local workloads; shared network filesystems and multi-replica
SQLite deployments are outside its support promise. MongoDB is supported only for generated
starter and blank projects on the authenticated TLS three-member replica-set,
Linux x86-64 profile documented in its guide. The three adapters implement the same portable Store
boundary; database selection does not create a private application API.