Secrets Manager costs

Tensor9 BYOC planning comparisons for aws::1.0.0::secretsmanager, with backend choices shown together. Read how Tensor9 estimates service-adapter costs for price scope and capacity qualification, or return to additional services.

​

AWS Secrets Manager → Key Vault

Origin API: aws::1.0.0::secretsmanager. Target backend: azure::1.0.0::keyvault.

​

AWS Secrets Manager · Secret API reads

Estimated monthly service charges by Secret API reads. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → eastus, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Provider reconciliation operations use the vault-operation tariff; Standard secrets have no storage meter.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-a5870b86a42807d366a1ccbb2d8d495c03fa4ea1 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSSecretsManager offer, Azure Retail Prices API.

​

AWS Secrets Manager · Stored logical secrets

Estimated monthly service charges by Stored logical secrets. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Inventory varies independently of monthly reads and mutations. Retention remains an explicit planning assumption. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → eastus, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Provider reconciliation operations use the vault-operation tariff; Standard secrets have no storage meter.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-a5870b86a42807d366a1ccbb2d8d495c03fa4ea1 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AWSSecretsManager offer, Azure Retail Prices API.

​

AWS Secrets Manager → Kubernetes Secret

Origin API: aws::1.0.0::secretsmanager. Target backend: tensor9::1.0.0::emu::aws/1.0.0/secretsmanager::kube.

​

AWS Secrets Manager · Secret API reads

Estimated monthly service charges by Secret API reads. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Self-hosted target: Tensor9-built Secrets Manager service on Kubernetes Secrets; no vendor tariff. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor tariff: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
• Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
• Network pricing: https://cloud.google.com/vpc/network-pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-3cc07bdd0f43f7beabfb1c23deaeed786570940f / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSSecretsManager offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

​

AWS Secrets Manager · Stored logical secrets

Estimated monthly service charges by Stored logical secrets. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Inventory varies independently of monthly reads and mutations. Retention remains an explicit planning assumption. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Self-hosted target: Tensor9-built Secrets Manager service on Kubernetes Secrets; no vendor tariff. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor tariff: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
• Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
• Network pricing: https://cloud.google.com/vpc/network-pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-3cc07bdd0f43f7beabfb1c23deaeed786570940f / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AWSSecretsManager offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

​

AWS Secrets Manager → Kubernetes Secrets

Origin API: aws::1.0.0::secretsmanager. Target backend: external-secrets::1.0.0::secret-store.

​

AWS Secrets Manager · Secret API reads

Estimated monthly service charges by Secret API reads. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Self-hosted target: External Secrets Operator (Apache-2.0, https://github.com/external-secrets/external-secrets/blob/main/LICENSE); a backing secret provider, if any, bills separately. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor tariff: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
• Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
• Network pricing: https://cloud.google.com/vpc/network-pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-e3a242e51282ee051f406cb9f77beb9aecbf2294 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSSecretsManager offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

​

AWS Secrets Manager · Stored logical secrets

Estimated monthly service charges by Stored logical secrets. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Inventory varies independently of monthly reads and mutations. Retention remains an explicit planning assumption. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Self-hosted target: External Secrets Operator (Apache-2.0, https://github.com/external-secrets/external-secrets/blob/main/LICENSE); a backing secret provider, if any, bills separately. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor tariff: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
• Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
• Network pricing: https://cloud.google.com/vpc/network-pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-e3a242e51282ee051f406cb9f77beb9aecbf2294 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AWSSecretsManager offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

​

AWS Secrets Manager → OCI Vault

Origin API: aws::1.0.0::secretsmanager. Target backend: oci::1.0.0::vault.

​

AWS Secrets Manager · Secret API reads

Estimated monthly service charges by Secret API reads. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → us-ashburn-1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• OCI Secret Management has no charge for secret versions or retrieval; only an HSM-protected protecting key above 20 versions or a private vault (USD 3.724/hour) would bill, and the default software-protected key is free.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• OCI Secret Management: https://www.oracle.com/security/cloud-security/secrets/

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-a3102dfef67b819887de750afea3c1b456606428 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSSecretsManager offer, OCI Secret Management.

​

AWS Secrets Manager · Stored logical secrets

Estimated monthly service charges by Stored logical secrets. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Inventory varies independently of monthly reads and mutations. Retention remains an explicit planning assumption. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → us-ashburn-1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• OCI Secret Management has no charge for secret versions or retrieval; only an HSM-protected protecting key above 20 versions or a private vault (USD 3.724/hour) would bill, and the default software-protected key is free.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• OCI Secret Management: https://www.oracle.com/security/cloud-security/secrets/

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-a3102dfef67b819887de750afea3c1b456606428 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AWSSecretsManager offer, OCI Secret Management.

​

AWS Secrets Manager → Scaleway Secret Manager

Origin API: aws::1.0.0::secretsmanager. Target backend: scaleway::1.0.0::secret-manager.

​

AWS Secrets Manager · Secret API reads

Estimated monthly service charges by Secret API reads. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → fr-par, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Monthly resource quantity is stored secret versions; access requests are separate from local adapter reads. Restoring a version costs EUR 0.01 and is not modeled.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Scaleway Security and Account pricing: https://www.scaleway.com/en/pricing/security-and-account/

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-f1fcbcd483b59816d6c595395cd6fecb9f2ccdcf / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSSecretsManager offer, Scaleway Security and Account pricing.

​

AWS Secrets Manager · Stored logical secrets

Estimated monthly service charges by Stored logical secrets. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Inventory varies independently of monthly reads and mutations. Retention remains an explicit planning assumption. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → fr-par, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Monthly resource quantity is stored secret versions; access requests are separate from local adapter reads. Restoring a version costs EUR 0.01 and is not modeled.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Scaleway Security and Account pricing: https://www.scaleway.com/en/pricing/security-and-account/

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-f1fcbcd483b59816d6c595395cd6fecb9f2ccdcf / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AWSSecretsManager offer, Scaleway Security and Account pricing.

​

AWS Secrets Manager → Secret Manager

Origin API: aws::1.0.0::secretsmanager. Target backend: google::1.0.0::secret-manager.

​

AWS Secrets Manager · Secret API reads

Estimated monthly service charges by Secret API reads. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Monthly resource quantity is retained active provider versions, independent of logical source objects; access operations are separate from local adapter reads, and management operations are free. The account-wide free tier (6 versions, 10,000 accesses a month) is not applied.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Secret Manager pricing: https://cloud.google.com/secret-manager/pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-74be73a1c55cd94e18955e080cba3c0d8c54b8ff / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSSecretsManager offer, Secret Manager pricing.

​

AWS Secrets Manager · Stored logical secrets

Estimated monthly service charges by Stored logical secrets. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; card amounts show the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Exact sampled model outputs in USD/month. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation from planning assumptions; not benchmark calibrated. Lines connect evaluated samples; intermediate capacity and prices are not inferred. Unpriced means no target quote or cost difference is available within the sizing policy. Estimated allocation from planning assumptions; not benchmark calibrated. The sizing policy grows compute with translated work and peak headroom, memory with compute and working set, and disk with resident working state and reserve. Monthly usage is distinct from resident data; each workload’s assumptions define the translation. HA changes pricing, not this policy’s throughput estimate. Unpriced workloads exceed the policy’s configuration range; no silent vertical cap or automatic sharding is assumed.

• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

Curve assumptions

• Inventory varies independently of monthly reads and mutations. Retention remains an explicit planning assumption. Editable authored planning guesses, not verified provider tariffs, benchmark measurements or a commercial quote. Other native meters retain their explicitly displayed default quantities.
• Planning estimate · editable authored rates and sizing assumptions dated 2026-10-22; not verified provider prices. us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Explicit tariff samples are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• The External Secrets synchronization option has a different read path: source polling and its source-provider charges must be supplied separately. This family does not imply those source charges disappear.
• The adapter-state Kubernetes backend creates no additional Kubernetes Secret; cloud provider copies and history have separate retention.
• Monthly resource quantity is retained active provider versions, independent of logical source objects; access operations are separate from local adapter reads, and management operations are free. The account-wide free tier (6 versions, 10,000 accesses a month) is not applied.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers, 4 GiB per vCPU, at most 6.5 GiB per vCPU, 96 vCPU and 65,536 GiB disk follow Cloud SQL Enterprise custom machine limits (provider-documented, same page); 624 GiB is 96 × 6.5. Targets billed per node, unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, AWSSecretsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSecretsManager/current/us-east-1/index.json
• Secret Manager pricing: https://cloud.google.com/secret-manager/pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• Rotation-function execution, customer-managed encryption-key calls, geographic replica copies and External Secrets source polling.
• Taxes, discounts, credits and free-tier allowances unless explicitly reflected in edited rates.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-74be73a1c55cd94e18955e080cba3c0d8c54b8ff / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AWSSecretsManager offer, Secret Manager pricing. See the service catalog for operation coverage, supported directions and backend limitations.