The first model fully supported by WASTE is Kimi K3, a 2.78 trillion parameter mixture-of-experts model. We converted the original 1.42 TB checkpoint into a 982 GB container and ran the complete model on a MacBook Pro with 64 GB of unified memory. This is not a distilled, pruned, or reduced variant.

A typical execution currently looks like this:

$ waste run ~/models/k3.waste "What is the capital of Italy?"

waste: no --budget, using 46.24 GB of 64.00 GB
       (expert cache 17.56 GB)

The capital of Italy is Rome.

[16 tokens, 49.31 s, 0.32 tok/s]

The current performance, approximately one third of a token per second, is not yet suitable for most interactive applications. However, the result demonstrates that available RAM does not necessarily have to impose a hard limit on the total size of a model that can be executed locally.

WASTE is an initial step in a broader effort to make increasingly capable models available on hardware controlled by the people and organizations using them.

The goal is to provide greater control over infrastructure costs, data privacy, availability and deployment.

Moving the memory boundary

Kimi K3 is a mixture-of-experts model. Although it contains 896 routed experts, only 16 experts are selected in each layer for a given token.

Most of the model weights are therefore inactive at any particular point in the computation.

WASTE takes advantage of this property by separating the model into two main parts.

The model trunk remains resident in memory. The expert weights remain on NVMe storage and are read when selected by the router. Any remaining RAM is used as a bounded expert cache.

This changes the primary constraint. Instead of requiring the entire model to fit in memory, the system needs to retrieve the active portion of the model within an acceptable amount of time.

For K3, each token accesses approximately 17 GB of expert data. This makes storage bandwidth and cache behavior central to performance.

WASTE stores experts in a layout designed around this access pattern. The matrices required for one expert are adjacent and can be loaded with a single positional read. The engine bypasses the operating system page cache and manages expert caching directly, so its behavior remains representative even when the complete model is much larger than memory.

The runtime is written in C and has no external inference dependencies. Python is used for conversion and validation, but not during inference.

The project currently includes:

• an embeddable C API;

• a command-line client;

• an OpenAI-compatible HTTP server;

• CPU implementations for ARM and x86 systems;

• support for macOS, Linux and Windows;

• text and image input for Kimi K3.

The same engine also runs Kimi-Linear 48B from a 19 GB container at approximately 8.9 tokens per second on the same machine.

Developing through measurements

One of the most useful parts of this project has been the development process itself.

The repository includes a document called What we know, and how we know it. It records not only successful optimizations, but also assumptions and proposed designs that were later disproved by measurements.

We adopted a simple working rule:

Before starting a long or expensive operation, run a smaller real-world test capable of invalidating the underlying assumption.

This was particularly important because many operations in this project are expensive. Downloading the source model involves 1.42 TB of data. A complete conversion produces almost one terabyte of output. Changes to the expert format can require converting the model again.

Testing an assumption first is considerably less expensive than discovering a problem at the end of that process.

Storage placement

We initially planned to run the converted model from an external NVMe drive.

The nominal performance of the drive appeared sufficient, but conventional storage benchmarks did not represent the pattern used by WASTE. The engine reads expert-sized records from many different positions rather than processing one continuous file sequentially.

We therefore wrote a benchmark that reproduced the actual access pattern.

On the target machine, the external SSD reached approximately 0.94 GB/s. The internal SSD reached 12.78 GB/s.

The main limitation was the USB bridge in the external enclosure rather than the NVMe device itself.

As a result, the external drive is used for downloading and staging the source checkpoint, while the converted WASTE container is placed on the internal SSD.

This measurement changed an important deployment decision before the full model was downloaded and converted.

Working with the released architecture

Development started before the complete K3 checkpoint became publicly available. Early feasibility work was based on the published information and on measurements taken from Kimi-Linear, the closest available model from the same family.

When the K3 weights were released on July 27, 2026, we reviewed the actual configuration, tensor index and weight shapes.

The most important finding was that K3 uses a latent mixture-of-experts architecture.

The model has a hidden width of 7,168, but its routed experts operate on a projected width of 3,584. This reconciles the announced parameter count with the size of the released checkpoint and substantially reduces the amount of expert data that must be read for each token compared with a full-width implementation.

The released model also differed from our assumptions in several other ways, including its number of layers, attention heads, shared experts and attention implementation.

Those differences required changes to both the runtime and the memory model.

The initial projection based on the smaller model suggested that K3 might reach between 1 and 1.5 tokens per second on the target hardware. The final measured performance was closer to 0.3 tokens per second.

The earlier estimate did not sufficiently account for the size of the resident trunk, the resulting reduction in available cache memory, and the computational cost outside storage I/O.

The earlier projection remains in the repository together with an explanation of why it was inaccurate. Keeping that history makes the current limitations and the next optimization targets easier to understand.

Understanding the cache

Expert caching turned out to have a less intuitive behavior than expected.

K3 accesses approximately 17 GB of expert records for each token. If the expert cache is smaller than this working set, most entries are evicted before they can be reused by the next token.

Below this threshold, the measured cache hit rate is effectively zero.

Once the cache exceeds one token’s working set, reuse begins to provide a measurable benefit. However, increasing the cache indefinitely does not improve performance.

On the 64 GB test machine, larger memory budgets increased the reported cache hit rate while making inference substantially slower. The operating system began compressing and paging memory. An entry reported as present in the WASTE cache could therefore require a page fault before it was usable.

The engine remained within its configured allocation, but the machine as a whole was under memory pressure.

For this reason, WASTE does not attempt to consume all available memory. Its automatic planner allocates cache in multiples of the token working set and maintains a margin for the operating system and other processes.

On the test machine, a total budget of approximately 46 GB produced better results than larger allocations.

Approaches that did not improve the system

Several plausible approaches were tested and rejected.

A three-bit model trunk

Reducing the trunk from four bits to three freed more than six gigabytes of memory and increased the expert-cache hit rate.

It nevertheless reduced overall performance because the additional unpacking cost exceeded the I/O savings. More importantly, generation quality collapsed.

K3 was trained with quantization-aware training for its expert weights, but not for the rest of the model. The trunk therefore did not tolerate the same level of compression.

Variable precision by expert

The original format design allowed some experts to use three bits and others to use two, based on their relative importance.

Measurements showed that the quantization error was unusually uniform across experts and layers. An optimized allocation performed only marginally better than a random one.

Routing frequency does vary, but reducing the precision of infrequently used experts mainly saves disk capacity rather than the bytes read during normal inference. Disk capacity was not the main constraint.

The mechanism was therefore not implemented.

GPU and Metal execution

A Metal backend was implemented and verified for correctness. On the tested workload it was 22% slower than the CPU path.

WASTE performs many relatively small and dependent matrix-vector operations. This is not necessarily a favorable workload for GPU execution, particularly when the CPU implementation already operates near the system’s memory-bandwidth limits.

Metal remains available as an optional backend, but it is disabled by default.

Index-layout changes

A revised expert index layout produced a 1.44× improvement in an isolated microbenchmark.

After converting a complete 19 GB model to the new layout, the end-to-end engine showed no meaningful improvement. The microbenchmark did not accurately represent the effects of multiple threads sharing the processor cache.

This was a useful reminder that a valid local measurement may still be irrelevant to the complete system.

The optimizations that mattered

The first correct version of the engine expanded quantized expert weights into floating-point values before using them.

Profiling showed that dequantization accounted for most of the expert processing time.

WASTE now performs the matrix-vector operation directly from the residual vector quantization representation. It builds partial dot-product tables for each codebook and uses those tables when processing the expert rows.

The full expert matrix is never materialized.

This approach was adapted from work previously done in sqlite-vector, where lookup tables are used to accelerate operations over quantized vectors.

Together with threading, SIMD kernels and the removal of repeated table construction, this reduced Kimi-Linear inference from 2.15 seconds per token in the first correct implementation to approximately 0.12 seconds per token.

After each optimization, the output was compared with a PyTorch reference implementation. The final logits remain within a small numerical tolerance, with the same most likely tokens and the same top-token ordering.

Correctness has remained a requirement throughout the optimization process.

Why we built WASTE

Cloud inference is appropriate for many applications. It provides access to specialized hardware, predictable deployment and models that may be impractical to operate independently.

At the same time, relying exclusively on remote inference introduces trade-offs.

Sensitive information may leave the local environment. Applications depend on network connectivity and external service availability. Usage costs are tied to token volume. Providers retain control over rate limits, model availability and version changes.

Local inference offers a different set of properties:

• prompts and results can remain on the device;

• the application can continue operating without a network connection;

• infrastructure costs can be based on owned hardware rather than token consumption;

• model deployment and upgrades remain under the operator’s control.

The name WASTE originally referred to the underused compute, memory and storage already available on local machines while inference is routinely moved to remote infrastructure.

The acronym—Weight-Aware Streaming Tensor Engine—was chosen later.

The intention is not to argue that all inference should move away from the cloud. It is to make local execution a practical option in cases where privacy, cost control, offline availability or infrastructure ownership are important.

K3 as a reference point

Kimi K3 is intentionally a demanding first target.

Its converted container occupies 982 GB. Each token requires access to approximately 17 GB of expert data. Its resident trunk consumes most of the minimum memory budget, and the internal SSD is already operating close to its measured throughput limit.

These constraints make it useful as a reference case.

Problems that are difficult to observe on smaller models become visible at this scale. Memory accounting errors become gigabytes. Ineffective caching strategies become immediately measurable. Storage placement becomes part of the inference architecture.

Smaller models are significantly less demanding.

Kimi-Linear 48B requires a 19 GB container, can open with less than 2 GB of RAM and reaches approximately 8.9 tokens per second with an 8 GB budget on the same hardware.

This is closer to the initial practical use case for WASTE: running capable local models inside applications, agents and private infrastructure without requiring a large inference stack.

K3 helps establish how far the same architecture can be extended.

What comes next

WASTE is the first release in a planned series of work focused on local model execution.

The current priorities include:

• improving the performance of expert retrieval and processing;

• reducing the number of bytes read for each token;

• supporting additional model architectures;

• improving prefetching and cache persistence;

• simplifying model conversion and distribution;

• publishing pre-converted containers;

• improving support for systems with larger unified-memory configurations.

The immediate objective is not limited to making K3 faster. It is to develop a general runtime and model format that can support a range of local hardware, from relatively small systems to workstations with large amounts of memory and fast storage.

Some of the approaches we test will not produce useful results. As with this first release, we intend to document those findings rather than present only the successful experiments.

At its current speed, K3 running through WASTE is primarily a technical result rather than a general-purpose interactive deployment.

It nevertheless establishes that a model can be executed locally even when its total weights are many times larger than available memory.

Future work is now focused on improving efficiency, usability and model coverage.

WASTE is available under the Apache 2.0 license:

github.com/sqliteai/waste

This release represents the first step toward giving developers and organizations a practical way to run increasingly capable models on hardware they own, with direct control over data, operating costs and deployment.

First, there was SQL. Declared dead countless times, yet still at the center of much of modern software. SQL made it possible to organize enormous amounts of information efficiently and reliably, but it always imposed a precise model: tables, columns, relationships, indexes, and queries that developers needed to understand in detail.

Then came the NoSQL wave, and databases like MongoDB changed the perspective. No more rigid schemas, but flexible JSON documents that better matched how developers represented data in modern applications.

And yet, one thing never really changed.

To store information in a database, you still need well-defined operations such as INSERT or UPDATE. To retrieve information, you still need to know columns, keys, structures, or implementation details of the underlying engine.

In other words, databases still speak the language of the engine, not the language of humans or AI agents.

Let’s think about a very simple example.

Imagine we want to store the following information:

“Marco met Andrew in San Francisco to discuss a possible integration between SQLite AI and A51 Robotics.”

In the SQL world, we would probably need to create something like this:

CREATE TABLE meetings (
    id INTEGER PRIMARY KEY,
    person1 TEXT,
    person2 TEXT,
    city TEXT,
    topic TEXT
);
​
INSERT INTO meetings
VALUES (
    1,
    ‘Marco’,
    ‘Andrew’,
    ‘San Francisco’,
    ‘SQLite AI integration with A51 Robotics’
);

And later, to retrieve that information, we would need to know the database structure and write queries such as:

SELECT *
FROM meetings
WHERE person2 = ‘Andrew’;

Or:

SELECT *
FROM meetings
WHERE topic LIKE ‘%A51%’;

SQLite-Memory starts from a completely different idea.

The information can simply be stored by writing a Markdown file:

# Meeting Notes
​
Marco met Andrew in San Francisco
to discuss a possible integration
between SQLite AI and A51 Robotics.

No tables.
No columns.
No schema to design.

And most importantly, retrieval becomes natural.

You can simply ask:

“What did we discuss with Andrew?”

Or:

“What discussions did we have regarding A51 Robotics?”

Or even:

“Do you remember the meeting in San Francisco?”

Without knowing the name of a column, without knowing how the information was stored internally, and without writing SQL queries.

Because humans do not think in tables.
And AI agents do not either.

We believe the future of databases should be closer to how people actually think: natural language, context, and semantic memory.

SQLite-Memory was created precisely around this idea.

Instead of forcing users to design schemas and queries, SQLite-Memory lets them build persistent memory from simple Markdown files. The information is processed by a specialized parser, automatically structured, and made semantically searchable.

Search is no longer based solely on columns or keywords but on the meaning of the information itself.

Because we believe the future of databases is not just about storing data, but about making information understandable and accessible in the most natural way possible.

SQLite-Memory is available today as a native SQLite extension and is also built directly into the SQLite Cloud platform. We are also working on a new PostgreSQL version to bring the same paradigm to existing PostgreSQL infrastructures and AI-native applications.

Memory becomes truly powerful when it can be shared.

A personal memory is useful. A collective memory is transformative.

This is where SQLite-Sync comes into play.

SQLite-Sync allows semantic memories to be synchronized across devices, users, and AI agents while remaining fully offline-first. Knowledge created on a laptop can instantly become available on a phone, shared with a team, or incorporated into the working memory of multiple AI agents collaborating on the same tasks.

Traditional synchronization systems were designed around rows and records. Semantic memory introduces a different challenge: synchronizing knowledge, documents, and evolving context without losing meaning or creating conflicts.

To solve this problem, SQLite-Sync uses a new CRDT algorithm specifically designed for Markdown-based semantic documents. Instead of treating content as opaque text blobs, it synchronizes knowledge at the block level, making collaborative editing, agent-to-agent memory sharing, and distributed semantic knowledge bases possible even in unreliable or completely offline environments.

We believe this combination of semantic memory and offline-first synchronization represents a foundational building block for the next generation of AI applications, where humans and agents continuously create, refine, and share knowledge across the edge and the cloud without ever having to think about where that information is physically stored.

You either centralized everything in the cloud or pushed logic and data closer to the edge.

The cloud gave us scalability, coordination, and shared intelligence.
The edge gave us responsiveness, offline capabilities, and low-latency interactions.

For a long time, that compromise was acceptable.

AI changes that completely.

The next generation of applications will not tolerate the latency introduced by continuous network roundtrips. AI agents, local copilots, robotics, industrial systems, real-time collaboration tools, and modern mobile applications increasingly need to reason, store memory, and execute directly on-device. But at the same time, they still need synchronization, coordination, shared context, centralized learning, and distributed state.

This is where the traditional distinction between “cloud database” and “edge database” starts to break down.

Developers should not have to choose one or the other.

The future is both.

At SQLite AI, we believe the cloud vs edge debate is largely an implementation detail.

Applications should simply operate on data:

• locally when possible,

• globally when necessary,

• continuously synchronized,

• always available,

• always low latency.

The cloud should not be responsible for every interaction.
The edge should not become an isolated island.

What matters is creating an architecture where both sides work together naturally.

This is the direction we have been building toward over the past few months.

Not just hosted SQLite databases, but a complete infrastructure layer designed for local-first and AI-native applications.

One of the biggest pieces of this evolution is SQLite-Sync (aka CloudSync).

SQLite-Sync introduces CRDT-based synchronization for SQLite databases, allowing applications and devices to continue operating locally while remaining continuously synchronized with the cloud.

What makes this particularly interesting is that synchronization is no longer limited to SQLite Cloud databases. SQLite-Sync can now synchronize directly with PostgreSQL and Supabase as well.

That means developers can finally combine:

• SQLite running locally on devices and at the edge,

• with PostgreSQL acting as a centralized coordination layer in the cloud.

Without giving up offline support.
Without forcing every operation through a remote server.
Without introducing unnecessary latency into AI workloads.

This hybrid architecture is becoming increasingly important as more applications move toward local AI execution.

AI systems are fundamentally changing infrastructure requirements.

Traditional applications could tolerate waiting hundreds of milliseconds for requests to travel across the network.

AI-native applications cannot.

An AI agent continuously depending on cloud roundtrips for memory retrieval, vector search, or state synchronization quickly becomes inefficient and expensive. More importantly, it feels unnatural.

Modern AI systems increasingly need:

• local memory,

• local persistence,

• local vector search,

• local reasoning,

• local execution.

At the same time, they still need:

• synchronization across devices,

• shared organizational knowledge,

• centralized policies,

• distributed coordination.

This creates a new category of infrastructure problems that traditional cloud architectures were never designed to solve.

To support this shift, SQLite AI has evolved into a broader platform that spans both edge and cloud workloads.

SQLite-Vector brings high-performance vector search directly into SQLite, enabling semantic search and embedding-based retrieval workloads to run locally with minimal memory usage.

SQLite-Memory introduces persistent semantic memory for AI agents and applications, enabling the synchronization of markdown documents, structured knowledge, and long-term contextual memory across systems.

SQLite-Columnar extends SQLite with column-oriented analytics capabilities optimized for large-scale scans and aggregations.

Individually, these extensions solve specific technical problems.

Together, they form the foundation for a different way of building software.

We believe the next generation of applications will increasingly:

• execute locally,

• synchronize globally,

• reason on-device,

• operate even without connectivity,

• and continuously exchange state with the cloud.

The network becomes a synchronization layer rather than a hard dependency for every interaction.

This is especially important for AI.

As models become smaller, faster, and capable of running directly on consumer hardware, the bottleneck shifts away from inference itself and toward:

• synchronization,

• distributed memory,

• shared context,

• local persistence,

• and low-latency coordination.

That is the infrastructure layer we are focused on building.

And we believe SQLite is uniquely positioned to become one of the foundational technologies behind it.

Explore SQLite AI

• SQLite AI

• SQLite-Sync

• SQLite-Vector

• SQLite-Memory

• SQLite-Columnar

Every agent today accumulates knowledge: conversation history, user preferences, and research notes. That memory is what makes an agent useful.

But the moment you have more than one agent, memory becomes a distributed systems problem.

A fleet of agents, running on different devices, in different processes, often offline, will each learn independently.
Agent A analyzes climate data.
Agent B models infrastructure costs.
Agent C processes user feedback.

So whose memory is it, really?

The obvious answer is a shared database. But shared databases require coordination: locks, transactions, connectivity, and a central point of failure. The moment an agent goes offline, it either blocks or falls behind.

There is a better approach. It starts with a simple observation:

Text is not atomic.

Row-Level LWW: Almost but Not Quite Good Enough

Last-Writer-Wins (LWW) is the simplest CRDT strategy. When two replicas disagree, the value with the newer timestamp wins. It is deterministic and coordination-free.

For atomic values, flags, counters, short strings, it works perfectly.

But memory is not atomic.

A memory entry might be hundreds of words. Agents do not overwrite it entirely. They edit parts of it. Add a line. Refine a paragraph. Update a detail.

If two agents edit different parts of the same entry while offline, row-level LWW throws away one of those edits entirely.

Both agents made valid updates. Only one survives.

That is the gap.

Block-Level LWW: Changing the Unit of Conflict

The insight behind block-level LWW is simple:

Do not treat text as a single value. Treat it as a sequence.

Split the text into blocks, typically lines, though other granularities are possible, for example, delimited by \n.

Each block carries its own metadata:

• Site ID, who wrote it

• Version clock, when

• Fractional index, where it sits in the sequence, allowing inserts between existing blocks without reordering everything

Now the unit of conflict is not the entire document, but the individual line.

Concurrent edits to different blocks are preserved automatically.
Edits to the same block fall back to LWW.

Consider:

Task A - Status: pending
Task B - Status: completed
Relevant context: team review scheduled for Friday

Agent A edits line 1 offline:
Task A - Status: in-progress

Agent B edits line 3 offline:
Relevant context: team review moved to Monday

After sync:

Task A - Status: in-progress
Task B - Status: completed
Relevant context: team review moved to Monday

Both edits survive. No coordination. No conflicts to resolve.

This is not magic. It simply changes the unit of conflict. Instead of competing over an entire document, agents only compete over the specific lines they touch.

Why Markdown Is the Perfect Fit

Not all text formats behave well under this model. Markdown does.

Markdown is inherently line-oriented. Headers, lists, code blocks, and most structural elements align naturally with line boundaries. Even paragraphs are just sequences of lines separated by blanks.

This means:

• Edits tend to map cleanly to individual lines

• Structural boundaries match merge boundaries

• Conflicts are naturally minimized

Compare this with HTML or JSON, where structure and content are interleaved. A small edit can ripple across multiple lines and create artificial conflicts.

Markdown avoids this problem.

It also matches how agents behave. They mostly append new knowledge rather than rewrite everything. Block-level LWW handles insertions cleanly through fractional indexing.

The result is simple:

• fewer conflicts

• automatic merges

• human-readable output

Markdown as the Source of Truth

In sqlite-memory, markdown is the primary representation of agent knowledge.

Agents ingest markdown documents. The system:

• stores raw text in a content table

• computes embeddings locally

• indexes them for hybrid search using vector similarity and FTS5

The architecture is intentional:

The text is the truth. Embeddings are a cache.

This means:

• content can be synchronized independently

• embeddings can be regenerated anywhere

• no shared vector store is required

Here is what that looks like from an agent’s perspective:

-- Agent A
SELECT memory_enable_sync(’research’);
SELECT memory_add_text(’James Webb Space Telescope observations confirm...’, ‘research’);

-- Agent B
SELECT memory_enable_sync(’research’);
SELECT memory_add_text(’Great Barrier Reef bleaching events correlate with...’, ‘research’);

After sync:

SELECT memory_reindex();

Agent A can now answer questions about coral reefs.
Agent B can answer questions about space telescopes.

No direct communication. No shared embedding service. Only shared text.

What This Enables

This architecture unlocks a fundamentally different model of agent systems.

No single point of failure

Every agent holds a complete, queryable copy of memory.

Offline-first operation

Agents can ingest, search, and reason without connectivity. Sync happens opportunistically.

Selective sharing

SELECT memory_enable_sync(’context-name’);

Defines what is shared and what remains private.

Parallel knowledge accumulation

Agents can explore different domains independently and merge into a unified corpus without orchestration.

Human-readable memory

The source of truth is markdown. Anyone can inspect it. Debugging and auditing become straightforward.

The Mechanics of Sync

Sync happens in two rounds and it is entirely based on sqlite-sync:

SELECT cloudsync_network_sync(500, 3);
SELECT cloudsync_network_sync(500, 3);

The first round pushes local changes outward.
The second round pulls in changes that others propagated in response.

After that, the database converges.

Then:

SELECT memory_reindex();

Embeddings are generated locally for new content. Since they are keyed by content hash, this step is idempotent.

Why This Matters Now

We are moving from single agents to agent fleets.

Current memory architectures do not scale well:

• centralized vector databases introduce coordination

• API-based embeddings add latency and cost

• shared mutable state requires complex conflict resolution

This approach avoids those constraints.

It treats:

• text as a CRDT

• agents as independent, occasionally connected nodes

The result is a system that:

• degrades gracefully under network failure

• scales without coordination

• converges deterministically

For AI systems operating at the edge of connectivity, this is not an optimization.

It is the architecture.

About sqlite-memory

sqlite-memory is part of the SQLite AI ecosystem, a set of extensions that bring semantic search, local inference, and distributed sync to SQLite: https://github.com/sqliteai/sqlite-memory

Countless hours, days, and months studying, writing, testing. Most of the time in my head first, then with paper and pen and on a real computer at the end.

Just by looking at those pictures, I can again feel the pain, the intense sacrifice, the energy of the entire process, and, finally, the reward when everything worked as expected.

More on my Instagram.

It was intense, just books, pen and paper, my dedication, and my skills.

The creative process gives you back much more than the final result. You’ll end up with new connections, new ideas, new ways to see the same problem, and when you can finally “touch” the product, you realize that the sum is immensely greater than the parts.

After Creo (Creo was running on top of Gravity), I founded another startup, but I always felt that Gravity and what I learned during that time deserved more. I realize that I always try to find connections between what I built in those years and what I find in front of me today.

Today, you write in plain English, drink a cup of tea, and Claude or Codex or whatever you like more does all the effort for you. You are more like a director: you no longer feel the pain, you no longer manually craft every single detail, and most importantly, you no longer learn like every other human being has learned since there were humans on Earth.

Now I can write basically everything in a couple of days, which is honestly super cool, but I’ll end up learning nothing from the process. This scares me a lot.

I like to define this time, especially for the software industry, as “frighteningly exciting“.

The ability to fully understand a SQLite statement programmatically unlocks many interesting possibilities: query analysis, SQL transformations, tooling, and AI systems that interact with databases.

Unfortunately, building a SQLite parser is surprisingly difficult.

SQLite’s grammar has evolved for more than 20 years and includes many subtle rules around expression precedence, optional syntax, and compatibility quirks. The official parser is generated from a large parse.y file and is deeply integrated with the rest of the SQLite engine.

Over the years, I tried several approaches:

• writing a parser from scratch

• manually parsing specific statements like CREATE TABLE (https://github.com/marcobambini/sqlite-createtable-parser)

• modifying SQLite’s parse.y grammar

None of these attempts worked well. Most projects ended up either incomplete or too fragile to maintain.

Recently I decided to try again.

With the help of modern coding assistants, I was finally able to push through the complexity and build a standalone parser derived from SQLite’s official grammar.

The result is liteparser.

liteparser is a feature-complete, embeddable, high-performance parser for SQLite statements written in C.

SQLite statements are parsed into a structured AST that can be inspected, analyzed, or transformed programmatically, making it possible to build tools that understand and manipulate SQL queries safely without executing them.

This capability enables a wide range of tooling around SQLite, including query linters, SQL formatters, query analyzers, schema migration tools, database IDEs, and AI systems that need to reason about SQL.

Key characteristics:

• parses all SQLite statements

• generates a complete AST

• supports JSON representations of parsed queries

• statements can be inspected, analyzed, or transformed programmatically

• preserves SQLite operator precedence and grammar semantics

• uses arena allocation to minimize memory overhead

• works on native platforms and WASM

• easily embeddable in other programming languages

Because it derives from SQLite’s official parse.y, it behaves consistently with SQLite itself.

The library has been extensively tested using:

• the official SQLite test suite

• millions of fuzz-testing iterations

As the founder of SQLite AI, I decided to release liteparser as open source under the MIT license, so anyone can freely use it.

If you’re building tools that need to understand SQLite queries like linters, query analyzers, developer tooling, or AI systems, this library might be extremely useful.

const char *sql = "SELECT name FROM users WHERE age > 18;";
liteparser_ast *ast = liteparser_parse(sql);
liteparser_print_json(ast);

{
  "type": "select",
  "columns": ["name"],
  "from": "users",
  "where": {
    "op": ">",
    "left": "age",
    "right": 18
  }
}

Project:

https://github.com/sqliteai/liteparser

It isn’t.

Trains lose connectivity.
Factories operate behind firewalls.
Hospitals isolate systems.
Devices move, disconnect, and fail.

And yet we keep building applications that stop working the moment the cloud disappears.

This is not a limitation of hardware.
It is a limitation of mindset.

The cloud is not the computer

For the last decade, we have treated the cloud as the default execution environment.

Computation, storage, identity, and application logic are centralized, always online, and always remote.

This model breaks under real-world conditions.

Latency is unpredictable.
Costs grow without bounds.
Privacy is compromised by design.
Failure becomes systemic instead of local.

The cloud is a powerful coordination layer.
It is a terrible place to depend on for basic application behavior.

Software must survive reality

Applications should not stop working when connectivity degrades.
They should not lose data because a service is unavailable.
They should not require a round trip to a distant server to make progress.

An application that cannot function offline is not resilient.
It is incomplete.

Offline is not an edge case.
Offline is the baseline.

Edge-first is not cloud-last

Edge-first does not mean rejecting the cloud.
It means redefining its role.

The edge is where data is created.
The edge is where decisions must be made.
The edge is where users interact with software.

The cloud exists to coordinate, not to control.

Synchronization should be explicit.
Conflicts should be deterministic.
Failure should be local, not global.

Data belongs to the application, not the platform

Modern platforms encourage dependency.

Proprietary APIs.
Opaque execution.
Irreversible coupling.

This leads to lock-in, not reliability.

Applications should be portable.
State should be inspectable.
Logic should be reproducible.

A system you cannot debug locally is not under your control.

SQLite is the natural foundation of the Edge

SQLite is everywhere.

It is embedded, deterministic, battle-tested, and reliable.

It does not require a server.
It does not assume connectivity.
It does not hide complexity behind a network boundary.

SQLite already powers the edge, silently.

We believe it should power the application runtime itself.

An application is a database with behavior

Storage, computation, synchronization, security, and AI should not be separate services.
They should be capabilities of a single, local runtime.

Logic runs where the data lives.
State evolves deterministically.
Synchronization happens when possible, not when required.

This is not a return to the past.
It is a correction.

Determinism over magic

Automatic systems that cannot be reasoned about eventually fail.

We choose explicitness over convenience.

Synchronization must be observable.
Conflicts must be explainable.
Behavior must be replayable.

If you cannot reproduce it, you cannot trust it.

AI belongs on the device

Inference should not require a network round-trip.
Embeddings should not leak private data.
Learning should respect locality.

The edge is not too weak for AI.
The cloud is too far.

Build software that works without permission

Software should continue to function without connectivity, without subscriptions, and without centralized approval.

The best software does not ask for permission to exist.

Our commitment

We are building an Edge Application Platform based on SQLite.

One that runs locally, synchronizes explicitly, executes logic on-device, integrates AI where data lives, and remains portable and open.

The cloud is optional.
The edge is mandatory.

I am the founder of SQLite AI, we’re building an edge-first application platform based on SQLite, where apps run locally, work offline by default, and use the cloud only for coordination. Our goal is to treat SQLite as the application runtime, not just a storage layer.
We’ll be sharing more technical details and announcements soon.

When you see a local-first app that seamlessly syncs with other applications distributed worldwide, it feels like magic. Under the hood, a lot is happening, and it has to happen in the right order for the algorithm to preserve correctness..

The source code of this simple iOS and Android ToDo app can be found at: https://github.com/sqliteai/sqlite-sync/tree/main/examples/to-do-app

Let’s look more deeply at what really happens when a value in a local-first app (backed by SQLite) is INSERTed, UPDATEd, or DELETEd.

Initial setup

Suppose we have two users, Bob and Alice, each with a local SQLite database named todo.sqlite that contains the following table:

CREATE TABLE todo (
         id TEXT PRIMARY KEY NOT NULL,
         title TEXT,
         status TEXT
);

Initially, both databases are empty, and at some point, Alice adds a "Buy groceries" item to the todo table with status set to "in_progress". In SQL it can be translated to:

INSERT INTO todo (id, title, status)
VALUES ('ID1', 'Buy groceries', 'in_progress');

At the SQL level, this is just a row insert. But for the sync engine, this single INSERT is not enough information to replicate the change safely across peers. It needs to break the change apart and record causality.

How the sync engine intercepts the change

Most local-first systems hook into SQLite by setting up UPDATE / INSERT/DELETE triggers on the user table; this is usually the trick that enables the engine to know that Alice’s device just inserted a new row.

Once the engine is notified, it doesn’t just say “a row was added.” It splits the mutation into per-column events.
Why? Because CRDTs typically track each column independently so that two peers can edit different columns of the same row without overwriting each other.

For our INSERT, the engine conceptually turns it into three “column insertions”:

• (row=ID1, column=title, value=’Buy groceries’)

• (row=ID1, column=status, value=’in_progress’)

• (row=ID1, column=id, value=’ID1’) (implicit for primary key)

Each column is then annotated with causal metadata.

Metadata captured per column

For every column change, the engine typically stores:

• site_id: Unique id of the device/database (e.g. Alice’s phone).

• column_name: Which column changed (title, status, etc.).

• row_key: Encoded primary key (points back to the row in todo).

• column_version: A Lamport clock or hybrid logical clock (HLC) that totally orders changes from the same site.

• db_version: The current database-wide Lamport clock, used to detect if a peer has already seen this change.

• op_type: Flag describing if this is an insert/update/delete at the column level (some systems call this a “tombstone” or “causal length”).

• seq: Order of mutations within the same db_version (to preserve local transaction order).

In many implementations, this is stored in a hidden metadata_table, so Alice’s insert produces one entry per column with her site_id and incremented clocks.

Why we need column-level clocks

CRDT algorithms for documents, sets, and maps use per-field timestamps so that:

• If Bob changes status while Alice changes title, they can merge without conflict.

• If both change the same column, the highest clock (or other CRDT rule) wins.

This is what lets local-first apps avoid last-writer-wins bugs while still syncing automatically.

Sync: how Bob receives Alice’s change

When Alice later syncs with Bob (via any transport like HTTP, P2P, etc.):

1. Diff calculation:

   • P2P mode:

     • Alice asks Bob: “What db_version have you seen from me?”

     • Bob replies with the last db_version he knows for Alice’s site_id.

     • Alice then ships only the ops with db_version > Bob’s reply.

   • Server-orchestrated mode:
     Instead of talking directly, Alice contacts a sync service. The server keeps a version map (per-site_id last-seen db_version) for every client.

     • Alice uploads her new ops; the server updates Alice’s entry.

     • When Bob syncs, the server tells him which db_versions from each site he’s missing and streams just those ops.

       This centralizes fan-out, simplifies conflict-free catch-up, and avoids NAT/P2P issues while preserving CRDT semantics.

2. Operation shipping:
   Alice sends all new rows in metadata_table beyond that version.

3. Replay:
   Bob’s engine replays the ops in causal order:

   • If the row doesn’t exist, it creates it.

   • It writes the columns in the same order Alice used (seq).

   • It updates Bob’s local clock table so he doesn’t reapply the same ops later.

After the replay, Bob’s user-facing todo table looks exactly like Alice’s.

UPDATE under the hood

If Alice later runs:

UPDATE todo SET status = ‘done’ WHERE id = ‘ID1’;

• SQLite writes to the status cell.

• The engine captures the event (via trigger or hook).

• It generates a new column_version for status.

• Inserts a new op record into metadata_table with op_type = UPDATE.

• The old value stays in todo; CRDT history doesn’t store the previous value, just the new value + causal version.

When Bob syncs, his engine sees:

“status column of ID1 is now ‘done’ with version (Alice, 42)”
If Bob’s local version for status is lower, it overwrites; if higher, it ignores (or merges, depending on CRDT type).

DELETE under the hood

Deletes are usually implemented as a tombstone, not a physical row removal:

DELETE FROM todo WHERE id = ‘ID1’;

• Instead of dropping the row immediately, the engine writes an op with op_type = DELETE (tombstone).

• It may also store a delete clock per column or per row.

When Bob syncs, his engine:

• Marks the row as deleted if Alice’s delete clock > any of Bob’s column clocks.

• Some systems keep the tombstone forever; others GC it once all peers have seen it.

This ensures that if Bob was offline and later tries to update the deleted row, the system can detect and discard that update (since the delete happened causally later).

Putting it together

So a single user action like:

INSERT INTO todo VALUES (’ID1’, ‘Buy groceries’, ‘in_progress1’);

Triggers:

1. SQLite row write.

2. Engine hook intercept.

3. Mutation split into per-column ops.

4. Metadata: (site_id, row_key, column_name, column_version, db_version, op_type, seq).

5. Ops appended to a local CRDT log.

6. Later: network sync ships the ops.

7. Remote site replays ops in causal order, resolving conflicts column by column.

This mechanism — column-wise causality + Lamport clocks + tombstones + metadata_table shipping is what lets local-first apps built on SQLite remain offline-first, merge safely, and stay reactive.

Working Offline — and Why It Still Works

One of the most powerful aspects of a local-first architecture is that Alice and Bob can be offline for as long as they want and everything will still sync correctly later:

• Alice might go for a long train ride, shut down her phone, and come back online hours later.

• Bob could fly overseas with his phone in airplane mode for the entire trip.

While they’re disconnected, both can freely INSERT, UPDATE, and DELETE items in their local SQLite database. Each change is recorded in the hidden metadata_table with its site_id, per-column version, and db_version.

When the network becomes available again, the sync layer simply asks:

“What operations have I not yet seen from each site?”

It then ships and merges all missing ops using the causal metadata.

Because the system is based on CRDTs (Conflict-free Replicated Data Types), it provides what is called strong eventual consistency:

• Every replica eventually sees the same set of operations.

• Conflicting edits to different columns merge automatically.

• True conflicts (same column, same row) are resolved deterministically using the clocks.

The result: no matter how long someone stays offline or how messy the network conditions are, the databases will converge without human intervention or manual conflict resolution.

I’m the founder of SQLite AI, our mission is to make local-first sync with SQLite and AI on the Edge straightforward and reliable. If you’d like to experiment with a production-ready sync engine, the same kind of technology discussed in this article, you can explore it at: https://www.sqlite.ai/sqlite-sync

Share

But in practice, very few apps get offline support right. Most simply queue changes locally and push them when the network comes back (spoiler: this doesn’t really work). Eventually, users see a scary banner saying “changes may not be saved.”

The reason is simple: syncing is hard.

When you build a local-first app, you’ve effectively created a distributed system. Multiple devices can mutate data independently, sometimes offline, and later must converge to the exact same state without losing data.

There are two main challenges to solve:

1. Unreliable ordering

2. Conflicts

Let’s go through them.

1. Unreliable Ordering

In a distributed environment, events happen on multiple devices at different times. If you just apply them as they arrive, you get inconsistent results.

Example:

• Device A sets x = 3

• Device B sets x = 5

Both happen while offline.

When the devices sync, the final value of x depends on which update is applied first. That’s a problem.

Traditional backend databases solve this with strong consistency, but that requires global coordination—too slow and brittle for local-first systems.

Instead, we want eventual consistency: every device applies changes independently but eventually converges to the same result once all changes are known.

The challenge is figuring out the correct order of events without relying on a centralized clock (because the network might be down).

The Solution: Hybrid Logical Clocks (HLCs)

Surprisingly, there’s a simple solution to this seemingly hard problem: Hybrid Logical Clocks (HLCs).

HLCs generate timestamps that are:

• Comparable (can be sorted lexicographically)

• Causally consistent (encode the order in which events happened)

HLCs combine two pieces of information:

• Physical time (from the machine clock)

• Logical time (a counter that increments when clocks are out of sync or events happen too close together)

In plain terms, HLCs let devices agree on “what happened first” without perfectly synchronized clocks.

A Quick Example

Imagine two machines, A and B:

1. Machine A records an event at 10:00:00.100.
   → Its HLC becomes (10:00:00.100, 0) (time + counter).

2. A sends a message to B with this HLC.

3. Machine B’s clock shows 10:00:00.095 (slightly behind).
   When B receives the message, it advances its HLC to at least match A’s timestamp.

4. B’s HLC becomes (10:00:00.100, 1) — the counter increments to indicate this happened after A’s event.

Result:

• Event on A: (10:00:00.100, 0)

• Event on B: (10:00:00.100, 1)

Even though B’s physical clock was behind, we can now order events consistently across machines.

2. Conflicts

Even with proper ordering, conflicts still happen when two devices modify the same data independently.

Example:

• Initial balance = 100

• Device A: +20 → balance = 120

• Device B: -20 → balance = 80

When they sync, which value should “win”?
If you naively apply both updates, one overwrites the other—losing user data.

Most systems ask developers to write manual conflict resolution code, but that’s error-prone and hard to maintain.

The Solution: CRDTs

The right approach is CRDTs (Conflict-Free Replicated Data Types).

CRDTs guarantee two important properties:

• Commutativity: Order of application doesn’t matter

• Idempotence: Applying the same change twice has no effect

This means you can apply messages in any order, even multiple times, and every device will still converge to the same state.

One of the simplest CRDT strategies is Last-Write-Wins (LWW):

• Each update gets a timestamp (physical or logical).

• When two devices write to the same field, the update with the latest timestamp wins.

Example:

• Device A: balance = 120 at 10:00:00

• Device B: balance = 80 at 10:00:02

When syncing, the system keeps 80 because it was written last.

Why SQLite Is Perfect for This

When building a local-first app, you need a rock-solid local database. SQLite is the obvious choice: battle-tested, lightweight, and available everywhere.

That’s why we built our local-first framework as a SQLite extension.

Our approach (simplified):

• Every change is stored as a message in a messages table with:

  • timestamp (from HLC)

  • dataset (table name)

  • row (encoded primary keys)

  • column

  • value

Applying a message is as simple as:

1. Look up the current value

2. If the incoming timestamp is newer → overwrite

3. If it’s older → ignore

This guarantees convergence across devices, regardless of the sync order.

Why This Matters

This architecture makes syncing simple and reliable:

• Reliable: Survives weeks of offline use without data loss

• Deterministic: Final state always converges

• Minimal: Just a small SQLite extension, no heavy dependencies

• Cross-platform: The extension is available for iOS, Android, macOS, Windows, Linux, and WASM

Takeaways for Developers

• Stop faking offline support with request queues

• Embrace eventual consistency

• Use proven distributed-systems techniques like HLCs and CRDTs

• Keep it small and dependency-free

The result? Apps that are instant, offline-capable, and private by default — without the complexity of traditional client–server synchronization.

I’m the founder of SQLite AI, our mission is to make local-first sync with SQLite and AI on the Edge straightforward and reliable. If you’d like to experiment with a production-ready sync engine, the same kind of technology discussed in this article, you can explore it at: https://www.sqlite.ai/sqlite-sync

Over the years, a clear trend has emerged, one that I still watch closely: for every new problem, a new database seems to be invented. The space is incredibly fragmented; there’s always a vendor claiming to have just the right database for each specific challenge. This fragmentation has only accelerated with the rise of AI, bringing new requirements like column-oriented processing and vector search. I have a strong opinion about this: I believe a single database could efficiently solve 90% of use cases. But maybe I’m a little too biased to say that out loud.

In any case, there’s one issue I think should already be behind us: choosing one database over another. Or rather, it would be behind us if we really wanted to push for a technological leap, a true database of the future. Today, the market is neatly split between cloud-based databases and embedded databases running on devices, on the Edge. It’s as if these were fundamentally different technologies, as if under the hood, they weren’t essentially the same thing. But they are.

Anything you can solve with a Cloud database, you can solve with an Edge database, except for one big difference: in the Cloud, there will always be one unavoidable inefficiency, no matter how advanced the technology is, the speed of light. If my request starts in Milan and my server is halfway across the world, light will still take a finite time to travel. That latency, dictated by physics, can’t be eliminated. It doesn’t matter how efficient the database is or how powerful the server is: light will always take about 30 ms to travel from Milan to London, or worse, 100–120 ms to reach New York.

Over the years, different strategies have been introduced to mitigate this problem. The most obvious one is replicating the same database in multiple regions, ensuring each request is served from the nearest node. But this raises other challenges: guaranteeing consistent reads across all nodes, and managing the complexity of keeping such a system running. My startup has solved many of these issues, but there’s still one challenge that no architecture like this can fully overcome.

What happens if there’s no network? Or if the connection is too slow? Or if my device, robot, or drone can’t afford to wait even 20 ms for an answer, because it needs to process something in real time? In those cases, the Cloud isn’t an option. There’s no way to send a request to some server and expect an instant response.

Soon, our homes will be full of smart devices and domestic robots. But what if the WiFi goes down? Do the robots fall down the stairs because the server didn’t respond? Or worse, does our smart alarm system fail because its camera couldn’t recognize that the face it saw belonged to a family member? That would be completely unacceptable.

The answer lies in using the technology we already have. Still, with a shift in mindset: local-first should be the default standard for building apps, apps that aren’t disrupted by network issues, airplane mode, or any other variable we can’t control. If we want to deliver truly great user experiences, the database must be local. Requests should have zero latency, and the database should support the new features modern applications demand: AI, vector search, federated learning, offline sync, and embeddable logic.

All of this can be done today with SQLite, enhanced by a set of extensions built to tackle these new challenges. It must work at zero latency, in microseconds, and at the same time synchronize intelligently with the Cloud, only when the network allows it, automatically resolving conflicts caused by concurrent transactions.

SQLite is the most widely deployed software in the world, probably also the most rigorously tested, and one of the very few projects with guaranteed long-term support for the next 25 years. I’d even add that it’s also one of the most underrated pieces of software; too often dismissed as “just” an embedded database, when in reality it’s incredibly efficient as a server-side database too.

I may sound biased, my startup is dedicated to these very problems and is all-in on SQLite, but I truly believe that, as of 2025, it makes no sense to keep choosing between the Cloud and the Edge. We don’t need two separate solutions for the same problem. What we need is a unified solution that combines Edge and Cloud, delivered by a single vendor, with a single set of extensions and smart features that can handle every use case. At the end of the day, you need an efficient way to handle data; everything else, like the database engine, the transport layer, or the sync algorithm, is just an implementation detail.

After 25 years (SQLite was first released in 2000), it’s time to say “welcome back” to SQLite, because the next 25 years will be remembered as the era that opened up a new market, one where the speed of light is no longer a limitation but simply a measure of how fast our new solutions can be.

I’m the founder of SQLite AI, our mission is to make local-first sync with SQLite and AI on the Edge straightforward and reliable. If you’d like to experiment with a production-ready sync engine, the same kind of technology discussed in this article, you can explore it at: https://www.sqlite.ai/sqlite-sync

The typical requirements are not “billion-scale” datasets or cloud-only setups. Most developers want something that is:

• Memory-efficient (able to run comfortably on laptops, phones, and small servers).

• Fast enough to handle a few million multidimensional vectors.

• Simple to use within regular SQLite workflows.

When you look at the current offerings, there’s a gap.

Existing Options

• sqlite-vss (Alex Garcia)
  Built on Meta’s Faiss C++ library, but plagued by integration issues that ultimately led Alex to abandon it. He explains why here.

• sqlite-vec (Alex Garcia)
  A clean re-implementation in C, easier to maintain, exposing a brute-force search strategy. It works via virtual tables, which means vectors must live in separate tables and queries become more complex. (This is the one we first adopted and even sponsored.)

• libsql (Turso)
  Uses the HNSW DiskANN algorithm, a powerful choice, but the indexing phase can take hours. For many SQLite use cases, that indexing overhead is simply not practical. (It turns out that indexing is optional in libSQL, thanks https://substack.com/@penberg for the correction)

Why Try Something Different?

These projects are valuable experiments, but they didn’t solve the constraints we were facing: speed, memory limits, and natural SQL usage. Out of that frustration, we started prototyping an alternative, which eventually became sqlite-vector.

The idea was simple:

• Use a brute-force-like approach, but highly optimized.

• Implement hardware-specific distance functions (auto-selected at runtime).

• Support quantization, preloading into memory, and multiple data types (FLOAT32, FLOAT16, BFLOAT16, INT8, UINT8).

• Allow vectors to be stored in ordinary tables, with no special virtual tables required.

Benchmark Exploration

To understand the trade-offs, we ran tests with 100,000 vectors of dimension 384 (FLOAT32) on an Apple M1 Pro MacBook Pro (2021, 16GB RAM).

sqlite-vec (100,000 rows)

Insert-time:          1179.07 ms
Full-scan query time:   67.84 ms

sqlite-vector (100,000 rows)

Insert-time:          563.04 ms
Full-scan query time:  56.65 ms

8-bit quantization:   224.85 ms (one-time)
Quant-scan query:      17.44 ms
Quant-preload query:    3.97 ms
Quant-mem usage:       37.38 MB
Recall@20:             1.0000 (20/20) 

(We couldn’t complete the libsql test, as index creation ran for hours without finishing.)

All tests for sqlite-vector were run with a 30 MB memory cap.

Observations

• Insert time is ~50% faster than sqlite-vec.

• Plain query time is ~16% faster.

• With quantization, queries become 3× faster.

• With quantization + preload, queries run in under 4 ms, roughly 17× faster than sqlite-vec, while still achieving perfect recall.

• Memory usage stays low (37 MB for 100k vectors).

Perhaps most importantly, the queries do not need complex JOIN statements to retrieve all information bound to embeddings:

-- Create a regular table
CREATE TABLE images (
  id INTEGER PRIMARY KEY,
  embedding BLOB, -- store Float32/UInt8/etc.
  label TEXT
);

-- Run a nearest neighbor query on the quantized data
SELECT e.id, v.distance
FROM images AS e
JOIN vector_quantize_scan('images', 'embedding', '[12,22,11,243,...]', 20) AS v
  ON e.id = v.rowid;

Closing Thoughts

Vector search is becoming an essential feature in many modern applications; yet, the SQLite ecosystem lacks an extension that meets the everyday needs of its community. Most developers don’t need billion-scale indexes or hours-long indexing jobs. What they need is something lightweight, memory-efficient, and fast enough to handle a few million vectors, all while feeling like “regular SQLite.”

The SQLite ecosystem already has a few approaches to vector search, but none yet feel fully aligned with the everyday needs of SQLite developers: reasonable scale, fast enough queries, efficient memory use, and seamless SQL integration.

We believe the community could benefit from sqlite-vector, which is why we’ve made it entirely free for open-source projects.

If you’re experimenting with vector search in SQLite, I’d love to hear your experiences, whether with sqlite-vector, sqlite-vec, libsql, or your own experiments.

I’m the founder of SQLite AI, our mission is to make local-first sync with SQLite and AI on the Edge straightforward and reliable. If you’d like to experiment with a production-ready vector engine, the same kind of technology discussed in this article, you can explore it at: https://www.sqlite.ai/sqlite-vector