sqlite3 on Mac: macOS Ships a June 2025 Build Called 3.51.0

Yes, every Mac has sqlite3 built in. On the Mac mini M4 that runs this blog, macOS 26.4.1 has it at /usr/bin/sqlite3, and it says it is SQLite 3.51.0. The rest of the version string doesn't fit that label. Apple's source ID is dated 2025-06-12, but upstream released 3.51.0 on 2025-11-04, and Apple's binary is missing jsonb_each(), a function 3.51.0 added. The current upstream release is 3.54.0, out yesterday, October 9, 2026.

Being behind matters less day to day than the way Apple compiled it. I ran 27 one-line checks against Apple's binary and Homebrew's SQLite 3.53.4 on the same machine. Apple's build accepts a misspelled column name as a string, allows UPDATE ... LIMIT, which the Homebrew build rejects, can't load extensions, and caps function calls at 127 arguments. Below is what I found, why brew install sqlite doesn't change which sqlite3 you get, and how to work around each difference.

Is sqlite3 installed on Mac by default?

Yes. The CLI, the system library and the Python that comes with the Command Line Tools all report the same build:

$ /usr/bin/sqlite3 -version
3.51.0 2025-06-12 13:14:41 f0ca7bba1c5e232e5d279fad6338121ab55af0c8c68c84cdfb18ba5114dcaapl (64-bit)
$ file /usr/bin/sqlite3
/usr/bin/sqlite3: Mach-O universal binary with 3 architectures: [x86_64] [x86_64h] [arm64e]
$ /usr/bin/python3 -c 'import sqlite3; print(sqlite3.sqlite_version)'
3.51.0

The hash ends in aapl instead of upstream hex, and the SQLite source repository returns "No such object" for it, so it's Apple's own build ID rather than an upstream check-in. Loading /usr/lib/libsqlite3.dylib with ctypes returns the same version and source ID, so apps that link the system library get this build too. The file is 4,641,296 bytes on the sealed system volume, which means you can't replace it. All you can control is which sqlite3 runs first.

The 3.51.0 that predates 3.51.0

The SQLite release history lists 3.51.0 on 2025-11-04 with source ID fb2c931a…. Apple's copy is dated five months earlier. The one 3.51.0 feature I tested shows the difference:

$ /usr/bin/sqlite3 :memory: "select count(*) from jsonb_each('[1,2,3]');"
Parse error near line 1: no such table: jsonb_each
$ /opt/homebrew/opt/sqlite/bin/sqlite3 :memory: "select count(*) from jsonb_each('[1,2,3]');"
3

So the label means something like "a June 2025 trunk build on the way to 3.51.0." Features from 3.53.0 aren't there either: json_array_insert(), ALTER TABLE ... ALTER COLUMN ... SET NOT NULL and REINDEX EXPRESSIONS all fail on Apple's binary and work on 3.53.4.

Security fixes are harder to see from outside. I read the security notes for all 13 macOS Tahoe releases, from 26 through 26.7.1. Only the macOS Tahoe 26 notes have a SQLite entry, for CVE-2025-6965. Upstream fixed that in 3.50.2 on 2025-06-28, so Apple patched its June snapshot rather than updating it. The WAL-reset corruption bug that upstream fixed in 3.51.3 isn't a CVE, and none of the 13 notes mention it. SQLite's developers call it rare and say upgrading is "not an emergency." Neither the binary nor the notes show whether Apple backported that fix. This machine has automatic updates off and stays on 26.4.1, so I also can't see whether 26.5 through 26.7.1 changed the bundled version.

What Apple compiled differently

PRAGMA compile_options lists 73 options for Apple's build and 62 for Homebrew's. The ones that change behavior:

Double-quoted strings are back on

Apple's build sets SQLITE_DQS=3. That turns on what the SQLite quirks page calls a "misfeature": if a double-quoted name doesn't match a column, SQLite treats it as a string. Upstream turned this off in the CLI in 3.41.0 (2023). Apple's CLI still has it on:

$ /usr/bin/sqlite3 :memory: 'select "nosuchcol" from (select 1 as a);'
nosuchcol
$ /opt/homebrew/opt/sqlite/bin/sqlite3 :memory: 'select "nosuchcol" from (select 1 as a);'
Parse error near line 1: no such column: "nosuchcol" - should this be a string literal in single-quotes?

A typo in a WHERE clause returns no rows instead of an error. In DDL it's worse: CREATE INDEX vi ON v("nosuchcol") succeeds on Apple's build and creates an index on a constant string. To turn it off, put this in ~/.sqliterc:

.output /dev/null
.dbconfig dqs_dml off
.dbconfig dqs_ddl off
.output stdout

Without the two .output lines, .dbconfig prints its new setting every time sqlite3 starts, including in scripts that parse its output. The CLI finds ~/.sqliterc through the account's home directory, not $HOME, so pointing HOME somewhere else didn't load mine. For one-off commands, -cmd ".dbconfig dqs_dml off" works as well.

No extensions, in the CLI or in Apple's Python

Apple compiles with SQLITE_OMIT_LOAD_EXTENSION. In /usr/bin/sqlite3, .load is "unknown command or invalid arguments" and the load_extension() function isn't there, so extensions such as sqlite-vec or SpatiaLite won't load. The Command Line Tools Python (3.9.6) shows the same thing differently:

$ /usr/bin/python3 -c "import sqlite3; sqlite3.connect(':memory:').enable_load_extension(True)"
AttributeError: 'sqlite3.Connection' object has no attribute 'enable_load_extension'

The Python sqlite3 docs say this outright: some platforms, "notably macOS," ship SQLite without extension loading. Datasette's install guide lists the same AttributeError and suggests Homebrew. Homebrew's Python 3.14 on this machine links SQLite 3.53.4 and has the method.

Smaller differences

Setting	Apple 3.51.0	Homebrew 3.53.4
UPDATE/DELETE ... LIMIT	allowed	syntax error
Max function arguments	127	1000
Default cache_size	2000 pages (about 8 MB at 4096-byte pages)	-2000 (2,000 KiB)
Default journal_size_limit	32768 bytes	-1 (no limit)
checkpoint_fullfsync	on	off
uuid() in the CLI	yes	no

The first row can trip you up later. A script written against Apple's sqlite3 that uses DELETE ... LIMIT works on a Mac and fails with a syntax error on a stock SQLite build, such as the one Homebrew installs. checkpoint_fullfsync on means WAL checkpoints use F_FULLFSYNC, the slow flush I measured at 3,890 µs per write on this Mac's SSD in the RAM disk on Mac post. Ordinary commits still use plain fsync, because PRAGMA fullfsync is off by default in both builds.

How to get a current sqlite3 on Mac

brew install sqlite on its own doesn't do it. Homebrew's SQLite formula is keg-only: it installs to /opt/homebrew/opt/sqlite/bin and doesn't link into /opt/homebrew/bin, because macOS already ships SQLite. On this machine Homebrew SQLite was installed as a dependency, and the shell still found Apple's copy:

$ which -a sqlite3
/usr/bin/sqlite3
$ ls /opt/homebrew/opt/sqlite/bin
sqlite3

To use it, add /opt/homebrew/opt/sqlite/bin to the front of PATH in your shell profile, or call it by full path. For scheduled jobs the full path is safer. As the jq on Mac post found, a LaunchAgent with no PATH key gets /usr/bin:/bin:/usr/sbin:/sbin, so a bare sqlite3 there runs Apple's build even if your Terminal doesn't. The launchd plist environment variables post covers setting PATH in the plist. Homebrew also won't update it until you upgrade; the difference is in brew update vs brew upgrade.

Apple's build is fine for reading a database or quick queries. Use the Homebrew build if you need extensions, the newer JSON functions or ALTER COLUMN, or if you want typo'd column names to fail. This is the same thing I found with macOS's rsync and jq: the tool has the familiar name, but it's an older or different build.

FAQ

Is sqlite3 installed on Mac by default?

Yes. macOS includes /usr/bin/sqlite3 and the system library /usr/lib/libsqlite3.dylib. On macOS 26.4.1 both report SQLite 3.51.0 with a source ID dated 2025-06-12, which is earlier than the official 3.51.0 release of 2025-11-04. The current upstream release is 3.54.0.

How do I update sqlite3 on a Mac?

You can't replace /usr/bin/sqlite3 because it is on the sealed system volume. Install Homebrew's sqlite with brew install sqlite, then put /opt/homebrew/opt/sqlite/bin at the front of PATH or call that path directly. The formula is keg-only, so it is not linked into /opt/homebrew/bin and a plain sqlite3 command keeps running Apple's build until you change PATH.

Why can't I load SQLite extensions on macOS?

Apple compiles its SQLite with SQLITE_OMIT_LOAD_EXTENSION. The .load command and load_extension() function are missing from /usr/bin/sqlite3, and the Command Line Tools Python raises AttributeError for enable_load_extension. Use Homebrew's sqlite3 for the CLI and a Python built against a SQLite that allows extensions, such as Homebrew's Python.

Method: I measured everything above on a Mac mini M4 (Mac16,10, 16 GB) running macOS 26.4.1 (25E253) on October 10, 2026. I compared /usr/bin/sqlite3 with Homebrew's sqlite 3.53.4 by running 27 one-line SQL checks (in research/sqlite3-mac-raw/cases.tsv) against each with an in-memory database, diffing PRAGMA compile_options, pragma_function_list and pragma_module_list, and testing the ~/.sqliterc workaround by putting the file in place and then deleting it. I checked the Python behavior with the Command Line Tools Python 3.9.6 and Homebrew's Python 3.14.7. Release dates and source IDs come from the SQLite release history. The CVE information comes from SQLite's CVE page and Apple's security notes for all 13 macOS Tahoe releases. I didn't test Intel Macs, any macOS version other than 26.4.1, or the 3.54.0 release. I also can't tell whether Apple backported the WAL-reset fix. I'll recheck the bundled version when this machine updates.