Archive old MySQL data. Keep the history.

RDS MySQL 8.0: pair upgrade planning with a retention review

AWS lists July 31, 2026 as the end of standard support for RDS for MySQL 8.0, with Extended Support starting August 1, 2026. Aurora MySQL version 3 has a separate calendar: standard support ends April 30, 2028. Dates checked October 15, 2026; consult the linked AWS calendars for changes.

ColdCTL currently targets MySQL 8.4 InnoDB. MySQL 8.0 and Aurora compatibility are not qualified. Start an archival evaluation on a disposable, supported 8.4 copy; do not assume ColdCTL can remove data from your existing 8.0 production instance before an upgrade.

Use the upgrade review to decide which history belongs in the active database and which needs separate retrieval. Archiving does not end Extended Support enrollment or substitute for an engine upgrade. Removing rows alone does not guarantee a smaller provisioned instance, lower storage bills or reduced support fees.

• Discuss your upgrade and retention goals privately

Define cold records before moving them

A creation timestamp is a starting point, not a complete retention policy. Check whether old rows are still updated, referenced by active records, subject to a hold, or needed by application queries. Choose a business cutoff and document exceptions. Archiving closed events is a different operation from moving orders that are still in progress.

Preview a bounded selection and its query plan before exporting. Treat row-count and size estimates as planning inputs. Run representative queries on a disposable copy to understand the workload, and preserve the backup strategy used for database recovery.

Use indexed, restartable batch reads

For a table with an immutable created_at and a unique id, a (created_at, id) index is a candidate for ordered range scans. Inspect EXPLAIN for your schema and filters; an index name alone does not guarantee a cheap read. Avoid an ever-growing OFFSET. Persist the last completed key and resume strictly after that key.

The read-only example below illustrates a subsequent batch. The cutoff, cursor and batch size are examples, not production defaults. Store the cutoff for the entire run. Concurrent updates or backdated inserts can invalidate a simple cursor approach; choose a consistent snapshot, a write-stable dataset, or a reconciliation strategy before relying on it.

SELECT id, created_at, event_type
FROM audit_events
WHERE created_at < '2025-01-01 00:00:00'
  AND (created_at > '2024-06-01 12:00:00'
       OR (created_at = '2024-06-01 12:00:00' AND id > 42000))
ORDER BY created_at, id
LIMIT 1000;

Export files you can identify and verify

Map database values explicitly into Parquet: timestamps, timezone assumptions, decimals, unsigned integers, nulls and binary values need a documented representation. Keep source identifiers and selection bounds alongside the files so you can explain which rows each batch contains.

Publish a completed batch only after its files are durable. Record object keys, counts, schema and integrity evidence in a manifest, then checkpoint progress. A restart should distinguish a completed batch from an incomplete upload rather than silently duplicating or skipping records.

• Design a database-to-Parquet archive

Verification and deletion are separate gates

Verify expected files, completed batches, row counts, readable schemas and representative values. Test retrieval before considering any source removal. Counts cannot prove value fidelity, and a checksum cannot prove that the selection rule chose the right rows.

ColdCTL deletion uses verified archived keys and compares current values inside bounded transactions. Triggers and incoming foreign keys are refused; changed rows roll back the batch. Keep transactions bounded and monitor locks, replica lag and application latency. Foreign keys and cascading deletes need explicit review. Removing rows may make space reusable inside InnoDB without shrinking database files; physical reclamation is a separate operational decision.

Keep archived history useful

Choose partitions around expected retrieval patterns, such as event month, rather than every customer identifier. Preserve a catalog of dataset, time range, schema version and file locations. A reader should be able to find the relevant archive without listing every object in a bucket.

ColdCTL pairs customer-controlled Parquet archives with on-demand retrieval. It is intended for retained history, not low-latency application lookups. Start with the supported-database guide for MySQL limits and connector setup.

• Explore searchable archives
• Read the current implementation guide