SQLite + AI: The Database Revolution Nobody is Talking About (No Pinecone)

Open any developer forum this week and

you'll find the same fight. Pinecone,

Weaviate, PGVector, or Chroma. Which

vector database should I use? I've got

some bad news for everyone in that

thread. You are all arguing about the

wrong database because the one quietly

winning the AI race isn't new at all.

It's 25 years old and it's already on

your machine. It's SQLite. SQLite isn't

just old, it's the most deployed

database on Earth. The best estimate is

over 1 trillion of them running right

now. It's inside every Android phone,

every iPhone, every Mac, and every

browser tab you have ever opened. You

are surrounded by it. And here's what

changed. In the last 2 years, this

ancient little database quietly learned

how to do AI. The project is called

SQLite-vec.

It takes vector search, the engine

underneath every rag app, and drops it

straight into SQLite, which means your

whole vector database collapses into one

file, a single file. You could literally

email it to yourself. No Pinecone

account, no server to rent, no $60 a

month bill. Just a file and the SQL you

already know. That is the revolution

nobody is talking about, and it runs

deeper than one clever extension. Let me

show you. First, let's be honest about

the thing everybody copied. A normal rag

setup calls an embedding model, then

ships your vectors off to a hosted

vector database over the network, then

waits, then reranks, then hopes a good

answer comes back. That is four or five

moving parts just to find some similar

text.

Every box in that diagram is a service

you provision, a bill you keep paying,

and one more thing that can page you at

3:00 in the morning. Pinecone's paid

tiers start around $70 a month. For a

huge number of apps, that is wildly

over-engineered. And every single query

leaves your computer. Your user's

private data takes a round trip to

somebody else's cloud just to find three

paragraphs that rhyme with the question.

That should bother you a little more

than it does. Now, the sharp teams

already sensed this. They moved to

PGVector, bolting vectors onto Postgres

so they could stop running a separate

service. Good instinct. SQLite just

takes that same instinct one giant step

further. No server at all because SQLite

is already inside your app. Same

process, same memory, zero network hops.

No connection string, no API key, no

cold start. It is just sitting there

waiting to be used. So, what does SQLite

vec actually look like? You create a

virtual table and tell it your

embeddings are say 768 numbers wide. One

statement and you have a working vector

store.

Then you insert those embeddings right

next to your normal columns. Same table,

same file, one plain insert. Your text

and its meaning finally live in the

exact same place. And to search, you

write a select. Match against a query

vector, order by distance, limit 20.

That is a full nearest neighbor search.

The exact thing you are renting a whole

platform for and it is just SQL. Sit

with that for a second. No new query

language, no SDK to learn, no

proprietary vector dialect. If you can

write a select statement, you already

know how to do retrieval. And because it

is a real database, you can filter by

metadata in the same query. User ID,

date, a tag, and then rank by

similarity. Try doing that cleanly in a

bolt-on vector service and you'll be

there a while. Here's the part one

genuinely love. The old version,

sicklight-vss,

was a nightmare to compile. Alex Garcia

threw it out and rewrote everything as

one C file with zero dependencies. You

copy it in and it just runs. There's a

companion piece too. With a sister

extension, you can run the embedding

model itself inside sicklight. Raw text

goes in, vectors come out. The entire

pipeline living in a single process.

Worried about size? It can store each

vector as compact bytes or even single

bits with a matching distance function.

That is millions of vectors packed into

a file small enough to sync over a phone

connection.

You pick the distance that fits the job.

Straight line for raw closeness, cosine

for direction, or Hamming for those bit

vectors. The knobs a real vector

database hands you right inside a select

and the same file byte for byte runs on

a laptop, a server, a $5 Raspberry Pi,

and the phone in your pocket. You write

it once and it goes wherever SQLite

already is, which is again everywhere.

My favorite trick of all, compile it to

web assembly and it runs inside the

browser. The whole retrieval step

happens in the tab. Nothing, and I mean

nothing ever leaves the user's device.

Now the honest catch, sysko died vec

checks every vector one by one. Pure

brute force, no fancy index yet. On a

normal laptop that is still tens of

milliseconds into the hundreds of

thousands, even a few million rows. Push

past that and you'll want a dedicated

engine and that is completely okay. It's

not a Python only toy either. Alex

shipped bindings for JavaScript, Go,

Rust, and Ruby. Basically every language

you'd actually reach for on a real

project, but keep coming back to that

one file idea because it is genuinely

wild. Your data, your embeddings, and

your search index all live in a single

file you can copy, drop into get, back

up, or ship inside your app's binary. It

also pairs with SQLite's built-in

full-text search. Keyword matching and

vector similarity blended together in

one query, the hybrid search that

dedicated platforms will happily sell

you a subscription for. Add all of this

up and you get local first AI, a private

assistant that works on a plane, a

search box that costs you exactly zero

to run.

Retrieval with no cloud anywhere in the

picture and you're not trapped offline

either. The lib SQL Cloud added embedded

replicas read locally at memory speed

then quietly sync the same file up to

the cloud in the background. You get

both at once. Cloudflare saw this coming

years ago. Their database D1 is just

SQLite running across hundreds of cities

on the edge generally available since

2024. Millions of little databases

spread across the planet. Each one a

plain SQLite file you already know how

to query.

So, your database can now live a few

milliseconds from every user alive, and

it is still just a SQLite file

underneath. Take a second and let that

sink in. And then AI agents showed up

and broke the math completely. An agent

doesn't want one giant shared database.

It wants its own. A private memory for

every user, every session, every single

task. Thousands of tiny databases spun

up in a millisecond and thrown away

seconds later. One company looked at

that and had a genuinely contrarian

thought. The old question was, how big

can a single database get? The new

question is, how many can you create and

how fast? That company is Turso, and

they had been circling this for years.

First, they forked SQLite into libSQL,

the open version its authors never

allowed. And then they went a lot

further. Their next move is a little bit

insane. They are rewriting SQLite from

scratch in Rust, fully in the open,

built from day one for the age of

agents. And they went straight at

SQLite's biggest weakness. For 25 years,

only one thing could write to it at a

time. Turso shipped true concurrent

writes, up to four times faster, the

feature people begged for and never got.

That is not the only thing. One year in,

they have also shipped native vector

search, change data capture, full text

search, live encryption, materialized

views, and a build that runs right in

the browser.

This is a serious database now, not a

weekend science project. And how do you

trust a from-scratch database with your

data? You test it the way the aerospace

and FoundationDB people do, simulating

millions of chaotic failures

deterministically before it ever ships.

That is the bar, and the number they're

building toward is not a typo. Not

thousands of databases, not millions,

billions. Roughly one per agent, per

user, per whatever comes next. Over 200

people are contributing, and half the

core team is from outside the company.

After 25 years of a famously closed

codebase, SQLite is finally being

rebuilt in the open. And this is not

some fringe experiment. It's how Simon

Willison's tools log every model call,

how mobile apps ship a searchable

database inside the download, how

on-device AI is quietly being built

right now, today. So, am I telling you

to delete Postgres? No. At real scale,

with heavy filtering and billions of

vectors, a dedicated database still

wins. SQLite plus AI does not replace

everything, and it doesn't need to. But

that was never the point. The revolution

isn't some shiny new database. It's the

oldest, most boring one, the one already

on 4 billion devices quietly learning

how to think. SQLite plus AI. Keep an

eye on this one because almost nobody

else is. I'll see you in the next one.