Migration deep-dives, and what we learn giving AI agents governed access to production databases — written by the team building DBShifts.
A support ticket that says “ignore previous instructions” is harmless in a table and an attack the moment an agent reads it into its context. Allowlists and masking never look at what the data says.
Read articleWhen an agent starts doing something it shouldn't, the usual off switch is rotating the database password, which stops every other consumer too. A pause should hit one agent, on its next request, and be undoable.
6 min readTightening an AI agent's access is easy to type and hard to predict. Replaying last week's recorded requests against the new policy turns “what breaks?” from a guess into a list.
6 min readA live view of agent traffic that keeps its own counters will eventually disagree with the audit log, and then nobody trusts either. Ours computes every number from the log itself.
7 min readWe created a user with the read role, connected as it, and MongoDB confirmed the role on the live connection. Then it inserted a document and dropped the collection anyway.
6 min readAn AI agent never has to read a masked column to steal it. If it can put that column in a WHERE clause, row counts alone reconstruct the value character by character — and every audit line says the system worked.
7 min readAn agent re-reading the same 50 rows a thousand times is harmless. One reading 50 new rows a thousand times has taken your table. Every volume dashboard shows them as identical.
6 min readTables don't become collections by renaming them. Foreign keys, JOINs, transactions and fixed schemas all need a deliberate translation — here's how to think about each one before you migrate.
9 min readLicense pressure makes the decision; the data model details make the project. NUMBER precision, empty-string NULLs, identifier casing, PL/SQL — what actually changes when you move Oracle workloads to Postgres.
8 min readEvery database migration is one of three shapes. The right one depends on two numbers: how much downtime you can afford, and how fast your source data changes.
6 min readThe fastest way to leak customer data is copying production into staging. Masking during migration — not after — closes the window where real PII sits exposed in a lower environment.
6 min readA migration you've only run once — in production, under pressure — is a gamble. The teams that migrate calmly all do the same three things: rehearse, isolate failures, and keep the exit open.
6 min readSeven engines, forty-nine source→target combinations, one rule: a pair isn't supported until a real migration of real data passes row counts and checksums. Here's how our certification harness works.
8 min readTINYINT(1) booleans, unsigned integers, ENUMs, zero dates, AUTO_INCREMENT sequences — the eight type conversions that decide whether your MySQL → PostgreSQL migration is correct or silently wrong.
7 min readAn unsigned TINYINT that clips 255 to 127. A VARBINARY that silently keeps one byte. A NUMERIC that rounds through float64. Five real bugs our certification harness caught — all of them silent.
9 min readBulk-copy a live database and you've copied a moving target. CDC closes the gap: snapshot, stream the changes that happened meanwhile, stay in sync until cutover. Here's the architecture.
7 min readMatching row counts prove you moved the right number of rows — not the right rows. How DBShifts hashes every row on both sides of a migration, across engines that can't even agree what a value looks like.
8 min readDocuments don't have a schema — until you need one. How DBShifts infers relational structure from collections, handles Decimal128 and nested documents, and goes the other direction too.
6 min readDatabase migration is moving data from one database to another — between engines, versions, servers, or clouds — without losing or corrupting it. Here's what it involves, why it's harder than copying files, and how the process actually works.
7 min read