How to fix SQLITE_LOCKED_SHAREDCACHE: Conflict within shared cache in SQLite

What this error means

The SQLITE_LOCKED_SHAREDCACHE error is specific to SQLite's shared-cache mode, an optional feature that allows multiple connections within the same process to share a memory cache. In shared-cache mode, SQLite enforces table-level locking instead of database-level locking. When two or more connections attempt conflicting operations on the same table (or when a schema modification is pending), one connection receives SQLITE_LOCKED_SHAREDCACHE. This error differs fundamentally from SQLITE_BUSY. The SQLITE_BUSY error (code 5) occurs when separate database processes conflict over the database file. In contrast, SQLITE_LOCKED (code 6) occurs between connections in the same process that share a cache. The error cannot be resolved with busy timeouts or retry loops—if a lock conflict occurs in shared-cache mode, the operation has immediately failed. Shared-cache mode was designed in 2006 to save memory on embedded platforms but has been largely superseded by WAL (Write-Ahead Logging) mode, which provides better concurrency without the same locking limitations.

Typical symptoms

• Application receives SQLITE_LOCKED_SHAREDCACHE or error code 6 when executing queries
• Error occurs intermittently in multi-threaded or asynchronous code
• Multiple connections to the same in-memory (:memory:) database with shared cache enabled fail
• Schema modification operations (CREATE TABLE, DROP TABLE, ALTER TABLE) block concurrent reads
• Transactions with pending schema changes cause readers on the same shared cache to receive locking errors
• Retries and exponential backoff do not resolve the error

Common causes

1. Shared-cache mode is enabled when multiple connections access the same database in the same process
2. Two or more connections attempt concurrent write operations to the same table
3. A connection holds a write transaction on a table while another connection tries to read or write to it
4. Schema-level locking occurs when one connection modifies the database schema while others try to access tables
5. One connection is holding an open transaction with uncommitted schema changes, blocking readers with SQLITE_LOCKED_SHAREDCACHE even if they use PRAGMA read_uncommitted
6. Reader connections attempt to access a table while a writer is holding a schema-level lock

How to fix "SQLITE_LOCKED_SHAREDCACHE: Conflict within shared cache"

# Python - sqlite3
import sqlite3
conn = sqlite3.connect('database.db')  # Shared cache disabled by default

# If it was enabled, disable it
sqlite3.enable_shared_cache(False)

// Node.js - better-sqlite3
const Database = require('better-sqlite3');
const db = new Database('database.db');
// better-sqlite3 does not use shared cache mode by default

// JavaScript - sqlite3
const sqlite3 = require('sqlite3');
const db = new sqlite3.Database('database.db');
// sqlite3 does not use shared cache mode by default

// Go - go-sqlite3
import _ "github.com/mattn/go-sqlite3"
// Shared cache can be enabled via URI parameter
// To disable: do NOT use ?cache=shared in the connection string
db, err := sql.Open("sqlite3", "file:database.db")

import sqlite3
conn = sqlite3.connect('database.db')
conn.execute('PRAGMA journal_mode=WAL')
conn.close()

// Node.js - better-sqlite3
const Database = require('better-sqlite3');
const db = new Database('database.db');
db.pragma('journal_mode = WAL');

-- In SQLite directly
PRAGMA journal_mode=WAL;

import sqlite3
conn = sqlite3.connect('database.db')
conn.execute('PRAGMA read_uncommitted=1')
# Now SELECT queries will not attempt to obtain read locks

// Node.js - better-sqlite3
const Database = require('better-sqlite3');
const db = new Database('database.db');
db.pragma('read_uncommitted = 1');

PRAGMA read_uncommitted=1;

import sqlite3
from threading import Lock

class DatabaseQueue:
    def __init__(self, db_path):
        self.conn = sqlite3.connect(db_path)
        self.lock = Lock()

    def execute(self, query, params=()):
        with self.lock:
            return self.conn.execute(query, params).fetchall()

db = DatabaseQueue('database.db')
# All operations are serialized through the lock
result = db.execute('SELECT * FROM users WHERE id = ?', (1,))

// Node.js - using a mutex or queue
const Database = require('better-sqlite3');
const Mutex = require('async-lock');

class DatabaseQueue {
    constructor(dbPath) {
        this.db = new Database(dbPath);
        this.lock = new Mutex();
    }

    async execute(query, params = []) {
        return this.lock.acquire('db', () => {
            return this.db.prepare(query).all(...params);
        });
    }
}

const db = new DatabaseQueue('database.db');
// All operations serialize through the lock

import sqlite3
conn = sqlite3.connect('database.db')

# GOOD: Transaction is short and committed immediately
try:
    conn.execute('CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)')
    conn.commit()
except Exception as e:
    conn.rollback()
    print(f"Error: {e}")

# BAD: Transaction left open indefinitely
cursor = conn.cursor()
cursor.execute('CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)')
# If this transaction is not committed, other connections will be blocked

// Node.js - better-sqlite3
const Database = require('better-sqlite3');
const db = new Database('database.db');

// GOOD: Use transactions and commit immediately
const transaction = db.transaction(() => {
    db.exec('CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)');
});
transaction();

// BAD: Manual transaction left open
db.exec('BEGIN');
db.exec('CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)');
// If COMMIT is not called, schema changes block all other connections

Advanced notes

Frequently asked questions

What does "SQLITE_LOCKED (6)" mean?

The SQLITE_LOCKED_SHAREDCACHE error is specific to SQLite's shared-cache mode, an optional feature that allows multiple connections within the same process to share a memory cache. In shared-cache mode, SQLite enforces table-level locking instead of database-level locking. When two or more connections attempt conflicting operations on the same table (or when a schema modification is pending), one connection receives SQLITE_LOCKED_SHAREDCACHE.

How do I fix "SQLITE_LOCKED (6)"?

When using SQLite's shared-cache mode, connections within the same process experience table-level locking conflicts that return SQLITE_LOCKED_SHAREDCACHE (error code 6). Unlike SQLITE_BUSY (which occurs between separate processes), this error indicates a locking conflict between connections sharing the same cache and cannot be resolved with timeout settings.

What causes "SQLITE_LOCKED (6)"?

Shared-cache mode is enabled when multiple connections access the same database in the same process Two or more connections attempt concurrent write operations to the same table A connection holds a write transaction on a table while another connection tries to read or write to it

Is the "SQLITE_LOCKED (6)" error serious?

Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Related errors

• node-sqlite3: SQLITE_CANTOPEN: unable to open database file

  How to fix "Unable to open database file" in SQLite

  HIGH

• better-sqlite3: This statement has already been finalized

  How to fix "better-sqlite3: This statement has already been finalized" in SQLite

  MEDIUM

• Sequelize ConnectionError: SQLITE_CANTOPEN

  How to fix "Sequelize ConnectionError: SQLITE_CANTOPEN" in SQLite

  HIGH

• TypeError: This database connection is busy executing a query

  How to fix 'This database connection is busy executing a query' in better-sqlite3

  MEDIUM

• SQLITE_CORRUPT: The database disk image is malformed

  How to fix "SQLITE_CORRUPT: The database disk image is malformed" in SQLite

  CRITICAL

• SQLITE_READONLY: Attempt to write a readonly database

  How to fix "SQLITE_READONLY: Attempt to write a readonly database" in SQLite

  HIGH

Official resources & further reading

• 📚SQLite Official Documentation