/**
 * ClickHouse sizing bounds shared by the two packages that enforce them.
 *
 * `@fjall/generator` validates a caller-supplied volume size when scaffolding
 * or modifying an `infrastructure.ts` declaration; `@fjall/components-
 * infrastructure` validates the same value again at synth, where it becomes a
 * real EBS volume. Neither can import the other's bound — the construct
 * package depends on the generator, not the reverse, and the generator must
 * stay free of CDK — so a bound declared in either place is a bound the other
 * copies.
 *
 * That copy went wrong once already. `backupRetentionDays` reused the RDS
 * schema, capping at 35 (the AWS ceiling on RDS *automated* backups) while
 * the ClickHouse construct allowed 3650 (an S3 lifecycle) — so a legal
 * retention was rejected before it reached the construct that would have
 * accepted it. Both knobs now take their bounds from here, which is the only
 * arrangement in which the two enforcement sites cannot disagree.
 */
/** Smallest ClickHouse data volume, in GiB.
 *
 *  Below this the disk-critical alarm's free-space floor stops being a slice
 *  of the volume and becomes most of it, so the alarm reports "this disk was
 *  always too small" rather than "the disk is nearly gone". The construct
 *  enforces the floor-to-volume ratio directly (`resolveClickHouseStorage`);
 *  this is the same constraint expressed as a flat minimum, for the schema
 *  layer that has no view of the alarm configuration. */
export declare const CLICKHOUSE_MIN_STORAGE_GB = 100;
/** Largest ClickHouse data volume, in GiB — the gp3 ceiling (16 TiB). Beyond
 *  it EBS rejects the CreateVolume outright, so catching it early turns a
 *  mid-deploy rollback into a message. */
export declare const CLICKHOUSE_MAX_STORAGE_GB = 16384;
/** Lowest provisioned IOPS on a ClickHouse data volume — the gp3 baseline.
 *
 *  gp3 includes 3,000 IOPS in the volume price regardless of size; EBS
 *  rejects anything lower, so there is no cheaper setting to express. */
export declare const CLICKHOUSE_MIN_IOPS = 3000;
/** Highest provisioned IOPS on a ClickHouse data volume — the gp3 ceiling.
 *
 *  Above 16,000 the instance's own EBS bandwidth, not the volume, is usually
 *  the binding limit; the ceiling is still the service's, because the
 *  instance type is the caller's choice and a bound that tracked it would
 *  reject a legal volume on a large host. */
export declare const CLICKHOUSE_MAX_IOPS = 80000;
/** Most provisioned IOPS EBS allows per GiB of gp3 volume (500 IOPS/GiB).
 *
 *  Coupled to `storageGb`: 80,000 IOPS needs a 160 GiB volume, so a small
 *  volume cannot carry the top of the IOPS band. The construct enforces the
 *  pair; this is the constant both its check and its message read. */
export declare const CLICKHOUSE_MAX_IOPS_PER_GB = 500;
/** Lowest provisioned throughput on a ClickHouse data volume, in MiB/s — the
 *  gp3 baseline, included in the volume price like the baseline IOPS. */
export declare const CLICKHOUSE_MIN_THROUGHPUT_MBPS = 125;
/** Highest provisioned throughput on a ClickHouse data volume, in MiB/s —
 *  the gp3 ceiling. */
export declare const CLICKHOUSE_MAX_THROUGHPUT_MBPS = 2000;
/** IOPS EBS requires per MiB/s of gp3 throughput (a 4:1 ratio — the service
 *  quotes it as 0.25 MiB/s per IOPS).
 *
 *  Coupled to `iops`: 1,000 MiB/s needs 4,000 IOPS, so raising throughput on
 *  a baseline-IOPS volume is rejected by EBS until IOPS rises with it. The
 *  construct enforces the pair and names the IOPS the throughput needs. */
export declare const CLICKHOUSE_IOPS_PER_THROUGHPUT_MBPS = 4;
/** Shortest ClickHouse backup retention, in days.
 *
 *  One day is the floor because the backup task runs daily: a retention below
 *  the backup interval expires each backup before its successor exists, which
 *  is a window with no backup at all rather than a short history. */
export declare const CLICKHOUSE_MIN_BACKUP_RETENTION_DAYS = 1;
/** Longest ClickHouse backup retention, in days — ten years.
 *
 *  ClickHouse backups are S3 objects aged out by a lifecycle rule, so the
 *  ceiling is a sanity bound rather than a service limit. It is deliberately
 *  NOT the 35 the RDS knob carries: that is the AWS cap on RDS *automated*
 *  backups, a mechanism ClickHouse does not use. Sharing one schema across
 *  both is what rejected a legal ClickHouse retention before it reached the
 *  construct that would have accepted it. */
export declare const CLICKHOUSE_MAX_BACKUP_RETENTION_DAYS = 3650;
/** Every EC2 instance type the ClickHouse construct supports, as data.
 *
 *  Two packages enforce this vocabulary and neither can import the other
 *  (same dependency shape as the bounds above): the construct keys its
 *  hardware-spec table on it (`CLICKHOUSE_INSTANCE_SPECS` is a
 *  `Record<ClickHouseInstanceType, …>`, so a type added here without a spec
 *  entry — or vice versa — fails to compile), and the generator validates a
 *  caller's `instanceType` against it at scaffold time, where the error
 *  names the legal values instead of surfacing as a synth throw mid-deploy.
 *
 *  This tuple exists because the two sites DID drift: the resilient and
 *  enterprise tier presets shipped `m6g.large`/`m6g.xlarge` — types the
 *  construct never supported — so both tiers scaffolded ClickHouse
 *  declarations that could not synthesise. A shared vocabulary makes that
 *  class of preset unrepresentable. */
export declare const CLICKHOUSE_INSTANCE_TYPES: readonly ["t4g.medium", "m7g.medium", "m8g.medium", "r7g.medium", "r8g.medium", "m7g.large", "m8g.large", "r7g.large", "r8g.large", "m7g.xlarge", "m8g.xlarge", "r7g.xlarge", "r8g.xlarge"];
export type ClickHouseInstanceType = (typeof CLICKHOUSE_INSTANCE_TYPES)[number];