> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Choosing an Adapter > Choose an origin-to-target service adapter from your application's requirements, target environment and operating model. Cloud Adapter lets your application keep using its origin-cloud API while another service performs the work. Choosing that service determines where data lives, how capacity is allocated, which operations share a transaction, and who operates the resources. A **service adapter is a directed origin-to-target pairing**. S3 → GCS and S3 → Azure Blob are different service adapters; GCS and Azure Blob are their respective target services, also called backends. In this section the application's origin service is usually fixed, so comparing backends means comparing adapters for that same origin. See [Key Concepts](/cloud-adapter/key-concepts) for the terminology and configuration scopes. Start with the environment your customer permits and the behavior your application needs. Then compare the eligible implementations. A backend that suits an independent key-value workload may be a poor choice for an order system that updates several records atomically. ## General trade-offs Each service article starts with the differences that matter across targets, then groups the available backends by **target environment**. Read the general considerations once, then use the article's table of contents to open your customer's environment. Within that section, compare the backend mechanisms, strengths, constraints and workload fit. Keep placement fixed while comparing backends. Cloud SQL and Azure Database for PostgreSQL are not two choices inside the same Google Cloud deployment. Where the catalog offers only one backend in an environment, evaluate whether that mapping meets the workload and which deployment settings matter; do not invent a second backend to fill a comparison table. ### Application requirements | Application scenario | Adapters to compare | Differences to examine | | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | DynamoDB tenant metadata in Google Cloud, with intermittent reads and secondary lookups | DynamoDB → Firestore and DynamoDB → Cloud SQL PostgreSQL | Numeric representation, index behavior, operation-based costs and provisioned database capacity | | DynamoDB order and ledger writes in Google Cloud | Compare Cloud SQL PostgreSQL and Spanner for the actual multi-item transaction. | Growth, placement, connection budgets and the capacity floor change the fit. | | SQS independent background jobs in Google Cloud | SQS → Pub/Sub and SQS → Cloud SQL PostgreSQL | Processing leases, recovery state, broker operations and database operations | | SQS ordered customer events in Azure | Compare the FIFO mappings for Service Bus and PostgreSQL. | Per-group sequencing, receipt recovery and database operating responsibility matter more than a general queue throughput figure. | The articles explain when an option fits a workload and which constraints can exclude it. These are conditional choices, not a ranking of providers or a default backend. Your requirements and measurements determine the choice. ### Define the application requirement Write requirements as observable behavior. “Uses DynamoDB” is too broad. “A failed inventory condition must leave both the order and stock unchanged” identifies a transaction requirement that can be checked. Include the less visible callers: background workers, administrative scripts, infrastructure tools, reporting queries and recovery procedures. Record operation options as well as operation names. | Requirement | Question to answer | | ---------------- | ---------------------------------------------------------------------------------------------------- | | Data and queries | Which keys, indexes, numeric values, object versions or message attributes does the application use? | | Atomicity | Which changes must commit or fail together? | | Ordering | Is order required globally, per tenant, per message group or not at all? | | Failure handling | What may be retried? How does the application detect an ambiguous result? | | Placement | Which cloud, regions, networks and identities are permitted? | | Recovery | How much data loss and downtime can the application tolerate? | | Operations | Which team can provision capacity, receive alerts, upgrade components and restore state? | Separate hard requirements from preferences. Lower idle cost is a preference unless it is an actual budget constraint. Required atomicity or a customer residency boundary cannot be traded away by scoring other features more highly. ### Understand what supplies the behavior Two adapters can expose the same operation while using different mechanisms beneath it. The mechanism explains the relevant costs and responsibilities. | Mechanism | What to examine | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Native protocol | The target engine serves application connections directly. Check engine, extension, authentication and connection behavior. | | Translated native API | Cloud Adapter translates origin requests into target operations. Check request amplification, target identity, quotas and error handling. | | Adapter-maintained behavior | The adapter maintains resource identity, indexes, message leases or other state to provide the origin contract. Include that state in capacity and recovery planning. | These categories are not quality rankings. An adapter can provide useful behavior that the target API does not expose directly. What matters is the directed mapping's contract and the complete architecture that provides it. Read the [Amazon Web Services catalog](/cloud-adapter/service-catalog/aws/catalog) for exact service names and the selected service's operation and capability tables. This section explains the consequences of choosing a mapping; the catalog remains the detailed reference. ### Understand how selection is applied The comparison does not establish a default. Runtime selection follows configuration and the service's supported selection rules: * **One compatible backend:** the installation can resolve it from the origin and target environment. * **A documented deployment default:** resources use that choice according to the service's selection rules. Check the scope and any supported overrides. * **Several eligible backends:** a supported resource-creation selector, such as `t9:backend`, can make the choice explicit. Do not add service configuration rows just to repeat every catalog relationship. [Configuration Files](/cloud-adapter/configuration/files) explains the sparse configuration model and when a pre-provisioned dependency needs an explicit binding. For a local single-service trial, `tensor9 adapt svc run --origin ... --backend ...` explicitly chooses the pair for that process. That command is not evidence that every resource in a larger installation requires its own configuration row. See the concrete startup steps in the [DynamoDB](/cloud-adapter/trade-offs/aws-dynamodb) and [SQS](/cloud-adapter/trade-offs/aws-sqs) examples. Selection also has a scope. A table's throughput setting, a database instance's size and an account's billing mode are different choices. Before expecting two resources to be independently tunable, identify the physical capacity and failure boundaries they share. ### Compare the complete operating cost Compare candidates using the same workload: request mix, payload size, data volume, key distribution and quiet periods. Include the adapter process and the work it performs on the target. For a database, count index maintenance, transaction retries, connections, storage growth and recovery capacity. For a queue, count sends, receives, empty polls, lease renewal, backlog storage and dead-letter processing. For object storage, include retrieval, multipart staging and data transfer as well as stored bytes. Avoid concluding that consumption billing is always cheaper or that an existing database has spare capacity. Both depend on the workload and on who else shares the resources. Keep current price calculations with the deployment decision rather than treating a documentation example as a quote. ### Assign responsibility before deployment “Managed service” describes some provider responsibilities. It does not choose who receives your application's alert or approves a restore. Likewise, “adapter-maintained state” describes the software maintaining it, not a promise that Tensor9 staff operate the deployment. For a customer-operated installation, a decision record might assign responsibilities this way: | Component | Operating owner | What the owner must account for | | -------------------------------------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | Cloud Adapter process | Customer platform team | Deployment, upgrades, credentials, health, alerts and restart procedure | | Managed target service | Cloud provider for service infrastructure; customer platform team for its configuration | Capacity, access, backups and restore initiation | | Adapter metadata or coordination state | Customer platform team | Durable storage, backup coverage and restore order | | Application workflow | Vendor application team | Idempotency, correctness checks, migration and recovery acceptance | These are example assignments. Your vendor may operate the adapter instead, or one team may own all roles. Name that team and its required access. Review [Deployment](/cloud-adapter/deployment/overview) and [Operations](/cloud-adapter/operations/overview) for the selected operating model. ### Record a decision you can revisit A useful decision record preserves the alternatives, the application's requirements and the evidence used to make the choice. Before selecting an adapter, a comparison record might read: > For tenant metadata in Google Cloud, compare DynamoDB → Firestore with DynamoDB → Cloud SQL PostgreSQL. Both must pass the application's point-read, indexed-lookup and conditional-update checks. Firestore uses document/index operations; Cloud SQL uses provisioned PostgreSQL capacity and connections. Verify required numeric values, contention, index rollout and recovery on each. Record measured total cost for the same traffic, and name the team responsible for each deployment. Select only after comparing those results with the application's budgets and required behavior. After evaluation, add your selected pair and the evidence supporting it. Retain the results for the other candidates so a later change in requirements can be assessed without repeating assumptions as facts. Do not confuse choosing a backend with moving existing data. Migration may require copying data, recreating indexes, draining messages, catching up writes and changing traffic. A new `t9:backend` value is not a migration or rollback procedure. ## Compare backends in your target environment Open the origin service, then choose the target environment in its table of contents. A provider name identifies placement; the backend is the particular service that implements the mapping there. A private Kubernetes deployment remains a separate operating choice even when its cluster runs on machines rented from a public cloud. It is not automatically another mapping under that cloud's catalog entry. | Origin service | General considerations and environment-specific choices | | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | [DynamoDB](/cloud-adapter/trade-offs/aws-dynamodb) | Indexes, exact numbers, transactions and document, relational or distributed database backends | | [SQS](/cloud-adapter/trade-offs/aws-sqs) | Delivery leases, ordering, delayed work and message-service or PostgreSQL backends | | [RDS PostgreSQL](/cloud-adapter/trade-offs/aws-rds-postgresql) | Engine compatibility, managed service controls, extension requirements and customer-operated PostgreSQL | | [Aurora PostgreSQL](/cloud-adapter/trade-offs/aws-aurora-postgresql) | Reader topology, connection behavior, managed PostgreSQL services and customer-operated clusters | | [ElastiCache](/cloud-adapter/trade-offs/aws-elasticache) | Commands, memory, failover and managed or customer-operated cache engines | | [OpenSearch](/cloud-adapter/trade-offs/aws-opensearch) | Query behavior, indexing and the search services or operated clusters available in each environment | | [S3](/cloud-adapter/trade-offs/aws-s3) | Object behavior, placement, version history and native or customer-operated object stores | | [Lambda](/cloud-adapter/trade-offs/aws-lambda) | Packaging, invocation, concurrency and the execution services available in each environment | For each eligible backend, record both the reason it fits and the cost or constraint you accept. For example, an existing database operations team may make a PostgreSQL-backed queue practical, but its queue backlog still competes for database storage and write capacity. A managed message service moves that work into a separate service with its own delivery contract and capacity controls. If the permitted environment changes, repeat the eligibility check before carrying over a backend decision. The same workload can have a different set of adapters in another environment. ## Next steps Continue with [Worked Examples](/cloud-adapter/trade-offs/worked-examples), organized by target environment, then [Validating Your Choice](/cloud-adapter/trade-offs/validating-your-choice). The first compares choices across an application within a fixed environment; the second separates the adapter contract from the checks specific to your workload.