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
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.
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.
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 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.
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 and 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:
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 and Operations 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.
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.