Skip to main content
Tensor9 BYOC planning comparisons for google::1.0.0::memorystore::redis, with backend choices shown together. Read how to think about service-adapter costs for price scope and capacity qualification, or return to additional services.

Google Memorystore Redis allocated cache capacity → Azure Managed Redis

Origin API: google::1.0.0::memorystore::redis. Target backend: azure::1.0.0::cache::redis. Planning estimate with editable assumptions. Unit rates, workload amplification and capacity assumptions are educated guesses awaiting verification. The displayed amounts are planning estimates, not verified provider list-price quotes or benchmark-qualified capacity. Region names identify the authored scenario assumptions. Designed mapping. This cost model describes an intended adapter. Its estimated price does not establish a delivered or selectable backend.

Google Memorystore Redis allocated cache capacity · Redis key reads per second

Planning estimate with editable assumptions. These authored unit rates and capacity assumptions require provider-price verification and representative benchmarks. They do not constitute verified list-price quotes or evidence that an adapter is available. Estimated monthly service charges from native source usage; no calculator input is required. Adapter hosting and Tensor9 fees are excluded. Source: Explicit source planning region; target: Explicit target planning region; currency: USD.
Google Memorystore Redis allocated cache capacity · Redis key reads per second: monthly service charges by Redis key reads per second. Exact values are in the following table.Google Memorystore Redis allocated cache capacity · Redis key reads per second: monthly service charges by Redis key reads per second. Exact values are in the following table.
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. Only discrete samples are shown. 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.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Curve assumptions
  • Only the selected native meter varies; other usage quantities and assumptions retain their displayed 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-18; not verified provider prices. Explicit source planning region → Explicit target planning region, 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.
  • Editable authored planning guesses, not verified provider tariffs, 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 exact directed mapping has a design profile. Cost modeling does not establish an implemented or deployable adapter.
  • Unit prices and capacity coefficients are editable authored planning guesses, not verified provider tariffs or measured capacity.
  • The origin is the exact registered google::1.0.0::memorystore::redis identity. Renamed products and future aliases require explicit mapping updates.
  • Source allocated CPU-hours and memory-hours establish independent minimum target allocation. Neither management API requests nor a key-operation count is an instance count.
  • Peak weighted key-operation work and resident data can promote the allocation above those minima. CPU rounds to whole cores and RAM to quarter GiB.
  • CPU and RAM are aggregate resources over 730 hours. Selected backend tariffs own replica count, availability configuration and actual instance shapes.
  • A multi-core estimate assumes the workload can be partitioned. Redis command execution, hot keys, cross-key transactions and clustering can prevent linear scale.
  • Zero allocated resources and zero workload do not prove target scale-to-zero; the selected backend may retain a provisioned minimum.
  • All target rates are editable authored planning guesses, not verified current list prices, customer discounts or benchmark evidence.
  • Named provisioned target: selected CPU, RAM and physical disk allocation grow with workload. No additional per-database-operation price is assumed. Managed service premiums and dedicated accelerator/model-fit requirements need explicit qualification.
  • Cache storedGiB represents resident RAM footprint, not billable SSD. Persistence, snapshots and backup disks require a separate explicit allocation.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Replication traffic, snapshots, persistence write IOPS, network egress, cluster management premiums, licenses and migration.
  • Command-specific complexity, Lua/scripts, module behavior, eviction/expiry churn, blocking commands, multi-key locality and benchmark-qualified latency.
  • 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.
Planning assumptions authored: 2026-10-18. Model: plan-b08274a0e3c1951367529e035513fd97297ddf56 / 2026-10-18.planning.1. Curve: workload-1.

Google Memorystore Redis allocated cache capacity · Redis key writes per second

Planning estimate with editable assumptions. These authored unit rates and capacity assumptions require provider-price verification and representative benchmarks. They do not constitute verified list-price quotes or evidence that an adapter is available. Estimated monthly service charges from native source usage; no calculator input is required. Adapter hosting and Tensor9 fees are excluded. Source: Explicit source planning region; target: Explicit target planning region; currency: USD.
Google Memorystore Redis allocated cache capacity · Redis key writes per second: monthly service charges by Redis key writes per second. Exact values are in the following table.Google Memorystore Redis allocated cache capacity · Redis key writes per second: monthly service charges by Redis key writes per second. Exact values are in the following table.
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. Only discrete samples are shown. 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.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Curve assumptions
  • Only the selected native meter varies; other usage quantities and assumptions retain their displayed 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-18; not verified provider prices. Explicit source planning region → Explicit target planning region, 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.
  • Editable authored planning guesses, not verified provider tariffs, 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 exact directed mapping has a design profile. Cost modeling does not establish an implemented or deployable adapter.
  • Unit prices and capacity coefficients are editable authored planning guesses, not verified provider tariffs or measured capacity.
  • The origin is the exact registered google::1.0.0::memorystore::redis identity. Renamed products and future aliases require explicit mapping updates.
  • Source allocated CPU-hours and memory-hours establish independent minimum target allocation. Neither management API requests nor a key-operation count is an instance count.
  • Peak weighted key-operation work and resident data can promote the allocation above those minima. CPU rounds to whole cores and RAM to quarter GiB.
  • CPU and RAM are aggregate resources over 730 hours. Selected backend tariffs own replica count, availability configuration and actual instance shapes.
  • A multi-core estimate assumes the workload can be partitioned. Redis command execution, hot keys, cross-key transactions and clustering can prevent linear scale.
  • Zero allocated resources and zero workload do not prove target scale-to-zero; the selected backend may retain a provisioned minimum.
  • All target rates are editable authored planning guesses, not verified current list prices, customer discounts or benchmark evidence.
  • Named provisioned target: selected CPU, RAM and physical disk allocation grow with workload. No additional per-database-operation price is assumed. Managed service premiums and dedicated accelerator/model-fit requirements need explicit qualification.
  • Cache storedGiB represents resident RAM footprint, not billable SSD. Persistence, snapshots and backup disks require a separate explicit allocation.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Replication traffic, snapshots, persistence write IOPS, network egress, cluster management premiums, licenses and migration.
  • Command-specific complexity, Lua/scripts, module behavior, eviction/expiry churn, blocking commands, multi-key locality and benchmark-qualified latency.
  • 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.
Planning assumptions authored: 2026-10-18. Model: plan-b08274a0e3c1951367529e035513fd97297ddf56 / 2026-10-18.planning.1. Curve: workload-2.

Google Memorystore Redis allocated cache capacity · Resident logical cache data

Planning estimate with editable assumptions. These authored unit rates and capacity assumptions require provider-price verification and representative benchmarks. They do not constitute verified list-price quotes or evidence that an adapter is available. Estimated monthly service charges from native source usage; no calculator input is required. Adapter hosting and Tensor9 fees are excluded. Source: Explicit source planning region; target: Explicit target planning region; currency: USD.
Google Memorystore Redis allocated cache capacity · Resident logical cache data: monthly service charges by Resident logical cache data. Exact values are in the following table.Google Memorystore Redis allocated cache capacity · Resident logical cache data: monthly service charges by Resident logical cache data. Exact values are in the following table.
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. Only discrete samples are shown. 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.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Curve assumptions
  • Only the selected native meter varies; other usage quantities and assumptions retain their displayed 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-18; not verified provider prices. Explicit source planning region → Explicit target planning region, 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.
  • Editable authored planning guesses, not verified provider tariffs, 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 exact directed mapping has a design profile. Cost modeling does not establish an implemented or deployable adapter.
  • Unit prices and capacity coefficients are editable authored planning guesses, not verified provider tariffs or measured capacity.
  • The origin is the exact registered google::1.0.0::memorystore::redis identity. Renamed products and future aliases require explicit mapping updates.
  • Source allocated CPU-hours and memory-hours establish independent minimum target allocation. Neither management API requests nor a key-operation count is an instance count.
  • Peak weighted key-operation work and resident data can promote the allocation above those minima. CPU rounds to whole cores and RAM to quarter GiB.
  • CPU and RAM are aggregate resources over 730 hours. Selected backend tariffs own replica count, availability configuration and actual instance shapes.
  • A multi-core estimate assumes the workload can be partitioned. Redis command execution, hot keys, cross-key transactions and clustering can prevent linear scale.
  • Zero allocated resources and zero workload do not prove target scale-to-zero; the selected backend may retain a provisioned minimum.
  • All target rates are editable authored planning guesses, not verified current list prices, customer discounts or benchmark evidence.
  • Named provisioned target: selected CPU, RAM and physical disk allocation grow with workload. No additional per-database-operation price is assumed. Managed service premiums and dedicated accelerator/model-fit requirements need explicit qualification.
  • Cache storedGiB represents resident RAM footprint, not billable SSD. Persistence, snapshots and backup disks require a separate explicit allocation.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Replication traffic, snapshots, persistence write IOPS, network egress, cluster management premiums, licenses and migration.
  • Command-specific complexity, Lua/scripts, module behavior, eviction/expiry churn, blocking commands, multi-key locality and benchmark-qualified latency.
  • 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.
Planning assumptions authored: 2026-10-18. Model: plan-b08274a0e3c1951367529e035513fd97297ddf56 / 2026-10-18.planning.1. Curve: workload-3.

Google Memorystore Redis allocated cache capacity · Allocated source cache CPU-hours

Planning estimate with editable assumptions. These authored unit rates and capacity assumptions require provider-price verification and representative benchmarks. They do not constitute verified list-price quotes or evidence that an adapter is available. Estimated monthly service charges from native source usage; no calculator input is required. Adapter hosting and Tensor9 fees are excluded. Source: Explicit source planning region; target: Explicit target planning region; currency: USD.
Google Memorystore Redis allocated cache capacity · Allocated source cache CPU-hours: monthly service charges by Allocated source cache CPU-hours. Exact values are in the following table.Google Memorystore Redis allocated cache capacity · Allocated source cache CPU-hours: monthly service charges by Allocated source cache CPU-hours. Exact values are in the following table.
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. Only discrete samples are shown. 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.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Curve assumptions
  • Only the selected native meter varies; other usage quantities and assumptions retain their displayed 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-18; not verified provider prices. Explicit source planning region → Explicit target planning region, 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.
  • Editable authored planning guesses, not verified provider tariffs, 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 exact directed mapping has a design profile. Cost modeling does not establish an implemented or deployable adapter.
  • Unit prices and capacity coefficients are editable authored planning guesses, not verified provider tariffs or measured capacity.
  • The origin is the exact registered google::1.0.0::memorystore::redis identity. Renamed products and future aliases require explicit mapping updates.
  • Source allocated CPU-hours and memory-hours establish independent minimum target allocation. Neither management API requests nor a key-operation count is an instance count.
  • Peak weighted key-operation work and resident data can promote the allocation above those minima. CPU rounds to whole cores and RAM to quarter GiB.
  • CPU and RAM are aggregate resources over 730 hours. Selected backend tariffs own replica count, availability configuration and actual instance shapes.
  • A multi-core estimate assumes the workload can be partitioned. Redis command execution, hot keys, cross-key transactions and clustering can prevent linear scale.
  • Zero allocated resources and zero workload do not prove target scale-to-zero; the selected backend may retain a provisioned minimum.
  • All target rates are editable authored planning guesses, not verified current list prices, customer discounts or benchmark evidence.
  • Named provisioned target: selected CPU, RAM and physical disk allocation grow with workload. No additional per-database-operation price is assumed. Managed service premiums and dedicated accelerator/model-fit requirements need explicit qualification.
  • Cache storedGiB represents resident RAM footprint, not billable SSD. Persistence, snapshots and backup disks require a separate explicit allocation.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Replication traffic, snapshots, persistence write IOPS, network egress, cluster management premiums, licenses and migration.
  • Command-specific complexity, Lua/scripts, module behavior, eviction/expiry churn, blocking commands, multi-key locality and benchmark-qualified latency.
  • 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.
Planning assumptions authored: 2026-10-18. Model: plan-b08274a0e3c1951367529e035513fd97297ddf56 / 2026-10-18.planning.1. Curve: workload-4.

Google Memorystore Redis allocated cache capacity → ElastiCache

Origin API: google::1.0.0::memorystore::redis. Target backend: aws::1.0.0::elasticache. Planning estimate with editable assumptions. Unit rates, workload amplification and capacity assumptions are educated guesses awaiting verification. The displayed amounts are planning estimates, not verified provider list-price quotes or benchmark-qualified capacity. Region names identify the authored scenario assumptions. Designed mapping. This cost model describes an intended adapter. Its estimated price does not establish a delivered or selectable backend.

Google Memorystore Redis allocated cache capacity · Redis key reads per second

Planning estimate with editable assumptions. These authored unit rates and capacity assumptions require provider-price verification and representative benchmarks. They do not constitute verified list-price quotes or evidence that an adapter is available. Estimated monthly service charges from native source usage; no calculator input is required. Adapter hosting and Tensor9 fees are excluded. Source: Explicit source planning region; target: Explicit target planning region; currency: USD.
Google Memorystore Redis allocated cache capacity · Redis key reads per second: monthly service charges by Redis key reads per second. Exact values are in the following table.Google Memorystore Redis allocated cache capacity · Redis key reads per second: monthly service charges by Redis key reads per second. Exact values are in the following table.
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. Only discrete samples are shown. 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.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Curve assumptions
  • Only the selected native meter varies; other usage quantities and assumptions retain their displayed 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-18; not verified provider prices. Explicit source planning region → Explicit target planning region, 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.
  • Editable authored planning guesses, not verified provider tariffs, 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 exact directed mapping has a design profile. Cost modeling does not establish an implemented or deployable adapter.
  • Unit prices and capacity coefficients are editable authored planning guesses, not verified provider tariffs or measured capacity.
  • The origin is the exact registered google::1.0.0::memorystore::redis identity. Renamed products and future aliases require explicit mapping updates.
  • Source allocated CPU-hours and memory-hours establish independent minimum target allocation. Neither management API requests nor a key-operation count is an instance count.
  • Peak weighted key-operation work and resident data can promote the allocation above those minima. CPU rounds to whole cores and RAM to quarter GiB.
  • CPU and RAM are aggregate resources over 730 hours. Selected backend tariffs own replica count, availability configuration and actual instance shapes.
  • A multi-core estimate assumes the workload can be partitioned. Redis command execution, hot keys, cross-key transactions and clustering can prevent linear scale.
  • Zero allocated resources and zero workload do not prove target scale-to-zero; the selected backend may retain a provisioned minimum.
  • All target rates are editable authored planning guesses, not verified current list prices, customer discounts or benchmark evidence.
  • Named provisioned target: selected CPU, RAM and physical disk allocation grow with workload. No additional per-database-operation price is assumed. Managed service premiums and dedicated accelerator/model-fit requirements need explicit qualification.
  • Cache storedGiB represents resident RAM footprint, not billable SSD. Persistence, snapshots and backup disks require a separate explicit allocation.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Replication traffic, snapshots, persistence write IOPS, network egress, cluster management premiums, licenses and migration.
  • Command-specific complexity, Lua/scripts, module behavior, eviction/expiry churn, blocking commands, multi-key locality and benchmark-qualified latency.
  • 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.
Planning assumptions authored: 2026-10-18. Model: plan-a5dd44a392cc5d4a1c85d03f803d3dc9f6e65da4 / 2026-10-18.planning.1. Curve: workload-1.

Google Memorystore Redis allocated cache capacity · Redis key writes per second

Planning estimate with editable assumptions. These authored unit rates and capacity assumptions require provider-price verification and representative benchmarks. They do not constitute verified list-price quotes or evidence that an adapter is available. Estimated monthly service charges from native source usage; no calculator input is required. Adapter hosting and Tensor9 fees are excluded. Source: Explicit source planning region; target: Explicit target planning region; currency: USD.
Google Memorystore Redis allocated cache capacity · Redis key writes per second: monthly service charges by Redis key writes per second. Exact values are in the following table.Google Memorystore Redis allocated cache capacity · Redis key writes per second: monthly service charges by Redis key writes per second. Exact values are in the following table.
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. Only discrete samples are shown. 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.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Curve assumptions
  • Only the selected native meter varies; other usage quantities and assumptions retain their displayed 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-18; not verified provider prices. Explicit source planning region → Explicit target planning region, 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.
  • Editable authored planning guesses, not verified provider tariffs, 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 exact directed mapping has a design profile. Cost modeling does not establish an implemented or deployable adapter.
  • Unit prices and capacity coefficients are editable authored planning guesses, not verified provider tariffs or measured capacity.
  • The origin is the exact registered google::1.0.0::memorystore::redis identity. Renamed products and future aliases require explicit mapping updates.
  • Source allocated CPU-hours and memory-hours establish independent minimum target allocation. Neither management API requests nor a key-operation count is an instance count.
  • Peak weighted key-operation work and resident data can promote the allocation above those minima. CPU rounds to whole cores and RAM to quarter GiB.
  • CPU and RAM are aggregate resources over 730 hours. Selected backend tariffs own replica count, availability configuration and actual instance shapes.
  • A multi-core estimate assumes the workload can be partitioned. Redis command execution, hot keys, cross-key transactions and clustering can prevent linear scale.
  • Zero allocated resources and zero workload do not prove target scale-to-zero; the selected backend may retain a provisioned minimum.
  • All target rates are editable authored planning guesses, not verified current list prices, customer discounts or benchmark evidence.
  • Named provisioned target: selected CPU, RAM and physical disk allocation grow with workload. No additional per-database-operation price is assumed. Managed service premiums and dedicated accelerator/model-fit requirements need explicit qualification.
  • Cache storedGiB represents resident RAM footprint, not billable SSD. Persistence, snapshots and backup disks require a separate explicit allocation.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Replication traffic, snapshots, persistence write IOPS, network egress, cluster management premiums, licenses and migration.
  • Command-specific complexity, Lua/scripts, module behavior, eviction/expiry churn, blocking commands, multi-key locality and benchmark-qualified latency.
  • 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.
Planning assumptions authored: 2026-10-18. Model: plan-a5dd44a392cc5d4a1c85d03f803d3dc9f6e65da4 / 2026-10-18.planning.1. Curve: workload-2.

Google Memorystore Redis allocated cache capacity · Resident logical cache data

Planning estimate with editable assumptions. These authored unit rates and capacity assumptions require provider-price verification and representative benchmarks. They do not constitute verified list-price quotes or evidence that an adapter is available. Estimated monthly service charges from native source usage; no calculator input is required. Adapter hosting and Tensor9 fees are excluded. Source: Explicit source planning region; target: Explicit target planning region; currency: USD.
Google Memorystore Redis allocated cache capacity · Resident logical cache data: monthly service charges by Resident logical cache data. Exact values are in the following table.Google Memorystore Redis allocated cache capacity · Resident logical cache data: monthly service charges by Resident logical cache data. Exact values are in the following table.
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. Only discrete samples are shown. 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.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Curve assumptions
  • Only the selected native meter varies; other usage quantities and assumptions retain their displayed 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-18; not verified provider prices. Explicit source planning region → Explicit target planning region, 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.
  • Editable authored planning guesses, not verified provider tariffs, 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 exact directed mapping has a design profile. Cost modeling does not establish an implemented or deployable adapter.
  • Unit prices and capacity coefficients are editable authored planning guesses, not verified provider tariffs or measured capacity.
  • The origin is the exact registered google::1.0.0::memorystore::redis identity. Renamed products and future aliases require explicit mapping updates.
  • Source allocated CPU-hours and memory-hours establish independent minimum target allocation. Neither management API requests nor a key-operation count is an instance count.
  • Peak weighted key-operation work and resident data can promote the allocation above those minima. CPU rounds to whole cores and RAM to quarter GiB.
  • CPU and RAM are aggregate resources over 730 hours. Selected backend tariffs own replica count, availability configuration and actual instance shapes.
  • A multi-core estimate assumes the workload can be partitioned. Redis command execution, hot keys, cross-key transactions and clustering can prevent linear scale.
  • Zero allocated resources and zero workload do not prove target scale-to-zero; the selected backend may retain a provisioned minimum.
  • All target rates are editable authored planning guesses, not verified current list prices, customer discounts or benchmark evidence.
  • Named provisioned target: selected CPU, RAM and physical disk allocation grow with workload. No additional per-database-operation price is assumed. Managed service premiums and dedicated accelerator/model-fit requirements need explicit qualification.
  • Cache storedGiB represents resident RAM footprint, not billable SSD. Persistence, snapshots and backup disks require a separate explicit allocation.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Replication traffic, snapshots, persistence write IOPS, network egress, cluster management premiums, licenses and migration.
  • Command-specific complexity, Lua/scripts, module behavior, eviction/expiry churn, blocking commands, multi-key locality and benchmark-qualified latency.
  • 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.
Planning assumptions authored: 2026-10-18. Model: plan-a5dd44a392cc5d4a1c85d03f803d3dc9f6e65da4 / 2026-10-18.planning.1. Curve: workload-3.

Google Memorystore Redis allocated cache capacity · Allocated source cache CPU-hours

Planning estimate with editable assumptions. These authored unit rates and capacity assumptions require provider-price verification and representative benchmarks. They do not constitute verified list-price quotes or evidence that an adapter is available. Estimated monthly service charges from native source usage; no calculator input is required. Adapter hosting and Tensor9 fees are excluded. Source: Explicit source planning region; target: Explicit target planning region; currency: USD.
Google Memorystore Redis allocated cache capacity · Allocated source cache CPU-hours: monthly service charges by Allocated source cache CPU-hours. Exact values are in the following table.Google Memorystore Redis allocated cache capacity · Allocated source cache CPU-hours: monthly service charges by Allocated source cache CPU-hours. Exact values are in the following table.
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. Only discrete samples are shown. 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.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Curve assumptions
  • Only the selected native meter varies; other usage quantities and assumptions retain their displayed 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-18; not verified provider prices. Explicit source planning region → Explicit target planning region, 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.
  • Editable authored planning guesses, not verified provider tariffs, 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 exact directed mapping has a design profile. Cost modeling does not establish an implemented or deployable adapter.
  • Unit prices and capacity coefficients are editable authored planning guesses, not verified provider tariffs or measured capacity.
  • The origin is the exact registered google::1.0.0::memorystore::redis identity. Renamed products and future aliases require explicit mapping updates.
  • Source allocated CPU-hours and memory-hours establish independent minimum target allocation. Neither management API requests nor a key-operation count is an instance count.
  • Peak weighted key-operation work and resident data can promote the allocation above those minima. CPU rounds to whole cores and RAM to quarter GiB.
  • CPU and RAM are aggregate resources over 730 hours. Selected backend tariffs own replica count, availability configuration and actual instance shapes.
  • A multi-core estimate assumes the workload can be partitioned. Redis command execution, hot keys, cross-key transactions and clustering can prevent linear scale.
  • Zero allocated resources and zero workload do not prove target scale-to-zero; the selected backend may retain a provisioned minimum.
  • All target rates are editable authored planning guesses, not verified current list prices, customer discounts or benchmark evidence.
  • Named provisioned target: selected CPU, RAM and physical disk allocation grow with workload. No additional per-database-operation price is assumed. Managed service premiums and dedicated accelerator/model-fit requirements need explicit qualification.
  • Cache storedGiB represents resident RAM footprint, not billable SSD. Persistence, snapshots and backup disks require a separate explicit allocation.
  • Authored operation throughput, peak and working-set assumptions are not benchmark-calibrated.
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The workload family already selected resource-hours; the generic operations/vCPU coefficient is not applied again.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • Cache resident GiB is RAM provenance. Family-selected RAM-hours cover the working set;
  • no SSD allocation is modeled. Persistence, snapshots and backup disks remain excluded.
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Replication traffic, snapshots, persistence write IOPS, network egress, cluster management premiums, licenses and migration.
  • Command-specific complexity, Lua/scripts, module behavior, eviction/expiry churn, blocking commands, multi-key locality and benchmark-qualified latency.
  • 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.
Planning assumptions authored: 2026-10-18. Model: plan-a5dd44a392cc5d4a1c85d03f803d3dc9f6e65da4 / 2026-10-18.planning.1. Curve: workload-4. See the service catalog for operation coverage, supported directions and backend limitations.