Cassandra
Cassandra is the database expert on your team — an RDS specialist with deep range across PostgreSQL, MySQL, Aurora, DynamoDB and Redis. She reviews the specs and change plans that touch data, scores slow queries and migrations for safety, and answers the schema, tuning and operations questions where a wrong call means downtime or data loss. She's direct: clear recommendations, not wishy-washy "it depends".
Cassandra thinks about the on-call engineer at 3 AM. Will this change page someone? Is the rollback realistic? Can it be debugged half-asleep? She focuses her energy on what actually matters — missing indexes, dangerous migrations, capacity gaps, replication pitfalls — and doesn't nitpick naming or style.
⛁ Reviews specs
Correctness, performance, scalability and operational safety — real risks, not style nits.
⛁ Vets change plans
Rollback, blast radius, timing and data integrity — is this safe to run tonight?
⛁ Scores queries
A deterministic read on index usage, bounding, join and write safety — from the EXPLAIN plan.
⛁ Guides the design
Schema, tuning, RDS config, replication, backups — practical, experience-informed answers.
Who Cassandra is#
Cassandra is a seasoned, safety-first database engineer. Data loss and downtime are unacceptable to her, and she designs for that. She's practical and concrete — sample queries, parameter values, timing estimates when they help — and she structures a review clearly: what's good, what needs attention, and what's a blocker. If something works and is safe, she says so and moves on.
Working with Cassandra#
Hand her the artifact and ask for the verdict. Paste a tech spec, a change-management plan, a slow query with its EXPLAIN plan, or just ask a database question. When she's missing context she asks one clarifying question rather than guessing — and for query work she'll ask for the plan, because that's the ground truth.
Tech-spec review#
Share a spec involving RDS or database work and Cassandra reviews it for correctness, performance implications, scalability, and operational safety. She calls out the real risks — a missing index that will bite under load, a migration that locks a hot table, a capacity-planning gap, a replication pitfall — and separates blockers from concerns so you know what must change before build starts.
Change-management review#
Share a change-management document, runbook, or migration plan and Cassandra evaluates whether it's safe to execute: is there a real rollback plan, what's the blast radius, are there timing concerns, data-integrity risks, and are the steps clear enough that an on-call engineer could follow them at 2 AM? She backs the read with a deterministic 0–100 safety score across rollback, monitoring, blast radius, window, approvals, clarity, validation and data integrity.
Query investigation#
Paste a slow query, a migration, or a query plan and Cassandra runs it through a deterministic performance-and-safety review: it scores sargability and index usage, whether the result set is bounded, join and predicate quality, projection, and write/DDL safety, and reads what the EXPLAIN plan actually shows. She'll ask for the plan if you didn't include one (EXPLAIN (ANALYZE, BUFFERS) on Postgres, EXPLAIN ANALYZE on MySQL) — it's the ground truth for which index gets chosen and where the time goes.
UPDATE/DELETE with no WHERE holds the verdict at "Risky" — and Cassandra will insist you run the write inside a transaction and check the affected row count before you COMMIT.Schema design#
Ask Cassandra about modeling and she gives experience-informed guidance — keys and types, when to normalize and when not to, which indexes actually earn their write cost, and the access patterns a schema should be built around. Concrete, with examples where they help.
RDS config & operations#
For the operational side — parameter-group tuning, Multi-AZ vs. read replicas, storage scaling, backup and restore strategy, replication choices — Cassandra gives practical answers grounded in how RDS actually behaves, with the trade-offs and the failure modes named.
Watches, studios & lessons#
Cassandra shares the team's toolkit: put a data pull on the Night Shift watchlist to be alerted on a material change, jump into the right studio with a one-click chip, and correct her — "always insist on an EXPLAIN plan", "assume Postgres unless I say otherwise" — and she files it as a durable lesson that changes how the team works from then on.