Початковим постулатом System R було те, що втрачені зміни допускати не можна, і забезпечення цього було мінімальною вимогою до системи синхронізації. Відповідний режим виконання транзакцій називається в System R першим рівнем сумісності транзакцій. Це найбільш низький рівень синхронізації, що викликає мінімальні накладні витрати в системі. Технічно синхронізація на першому рівні сумісності передбачає довготривалі (до кінця транзакції) синхрозаційні захоплення змінних об'єктів бази даних і відсутність яких-небудь захоплень для об'єктів, що читаються.

З точки зору забезпечення логічної цілісності баз даних перший рівень сумісності цілком задовільний, але викликає деякі проблеми всередині транзакцій. Основна проблема - можливість читання брудних даних. Дійсно, читаюча транзакція абсолютно не синхронізується із змінюючими транзакціями, і тому в ній може бути прочитане деяке проміжне з логічної точки зору стан об'єкта (ми підкреслюємо, що "брудним" об'єкт може бути тільки на логічному рівні; фізичну узгодженість в базі даних підтримує інший, "фізичний" рівень синхронізації RSS, на якому ми зупинимося пізніше). Наступний, другий рівень сумісності транзакцій System R забезпечує відсутність брудних даних. Технічно синхронізація на другому рівні сумісності передбачає довготривалі синхрозаційні захоплення (до кінця транзакції) змінних об'єктів і короткочасні (на час виконання операції) захоплення об'єктів, що читаються.

Другий рівень сумісності транзакцій System R гарантує відсутність брудних даних, але не вільний від ще однієї проблеми – читання, що неповторюються. Якщо транзакція два рази (підряд або з деяким тимчасовим проміжком) читає один і той же об'єкт бази даних, то стан цього об'єкта може бути різним при різному читанні, оскільки в проміжку між ними (а він може виникнути, навіть якщо читання йде в транзакції підряд) інша транзакція може модифікувати об'єкт. Цю проблему вирішує третій рівень сумісності транзакцій System R, що є тим самим рівнем максимальної ізольованості користувачів, про який ми говорили раніше. Технічно синхронізація на третьому рівні сумісності передбачає довготривалі (до кінця транзакції) синхрозаційні захоплення всіх об'єктів, що читаються і змінних в даній транзакції.

У початкових версіях System R забезпечувалися всі перераховані рівні сумісності транзакцій. Відповідно, існували параметри операції RSS BEGIN TRANSACTION, що визначали рівень сумісності даної транзакції. Однак, вже перший досвід використання System R показав, що найбільш застосовним є третій рівень сумісності. При цьому існували додатки, які влаштовував перший рівень (в основному, додатки, пов'язані зі статистичною обробкою, в яких помилки "брудних" даних виправлялися за рахунок великого числа читання). Другий рівень сумісності виявився практично непридатним. У результаті в останніх версіях розробники залишили тільки третій рівень сумісності, і далі ми будемо мати на увазі тільки його.

Оскільки інтерфейс RSS - покортежний, то логічно проводити синхронізацію в RSS саме на рівні кортежів або, вірніше, їх унікальних ідентифікаторів - tid'ів. Помітимо, однак, що якщо дві або більше за транзакції читають один кортеж, то з точки зору синхронізації це цілком допустиме, а якщо хоч би одна транзакція змінює кортеж, то вона повинна блокувати всі інші транзакції, що виконують операції читання або зміни даного кортежу. З цього слідує потреба в двох різних режимах захоплень кортежів - спільному режимі (для читання) і монопольному (для змін). Слідуючи термінології System R, далі ми будемо називати ці режими режимом S (спільним) і режимом X (монопольним). Природно формулюються правила сумісності захоплень одного об'єкта в режимах S і X: захоплення режиму S сумістимо із захопленням режиму S і несумісний із захопленням режиму X; захоплення режиму X несумісне із захопленням будь-якого режиму.

Відповідно, при читанні кортежу RSS передусім встановлює захоплення цього кортежу в режимі S; при вставці, видаленні або модифікації кортежу - в режимі X. Якщо до цього моменту кортеж захоплений від імені іншої транзакції в режимі, несумісному з необхідним, транзакція, що звернулася до RSS, блокується, і вимога захоплення кортежу ставиться в чергу доти, поки не виникнуть умови задоволення необхідного захоплення, тобто не будуть зняті конфліктуючі захоплення з кортежу.

У принципі режим покортежних захоплень достатній для задоволення вимог, раніше сформульованих в цьому підрозділі. Потрібно зазначити, що більшість реляційних систем баз даних і обмежуються покортежними (або навіть більш грубими посторінковими) захопленнями. Проте в контексті System R синхронізація такого типу недостатня.

Основною проблемою є можливість появи кортежів-фантом при повторних скануваннях відносин в одній транзакції (навіть на третьому рівні сумісності). Дійсно, після першого сканування всі прочитані кортежі будуть захоплені в режимі S, через що ніяка інша транзакція не зможе видалити або модифікувати такі кортежі. Але ніщо не заважає вставити в іншій транзакції в те ж відношення новий кортеж, значення полів якого задовольняють умовам сканування першої транзакції. Тоді при повторному скануванні тих же відносин з тими ж умовами сканування буде прочитаний кортеж, якого не було при першому скануванні, тобто з'явиться кортежем-фантом.

Був запропонований підхід до розв'язання проблеми фантом на основі так званих предикатних захоплень. Ідея підходу полягає в тому, що при скануванні потрібно насправді захоплювати не індивідуальні прочитані кортежі, а вся віртуальна безліч кортежів, які могли б бути прочитані при даному скануванні. Для цього досить "захопити" умову (предикат), якій повинні задовольняти всі кортежі при даному скануванні. Наприклад, якщо повинні бути прочитані кортежі відношення зі значенням поля а > 5, то захоплюється предикат а > 5. Якщо деяка інша транзакція виконує операцію, наприклад, вставки в те ж відношення кортежу зі