Node.js SDK Still Requires Sqlite3 Despite setting `disableHistory: true`

[barclayd]

🐛 Describe the bug

Context

I'm running Mem0, using Node.js SDK, deployed to AWS Lambda with the following config:

const memory = new Memory({
  version: 'v1.1',
  disableHistory: true,
  embedder: {
    provider: 'openai',
    config: {
      apiKey: env.OPENAI_API_KEY,
      model: 'text-embedding-3-small',
    },
  },
  vectorStore: {
    provider: 'opensearch',
    config: {
      collectionName: env.OPENSEARCH_COLLECTION_NAME,
      dimension: 1536,
      host: env.OPENSEARCH_ENDPOINT,
      port: 443,
      embedding_model_dims: 1024,
      use_ssl: true,
      verify_certs: true,
    },
  },
  llm: {
    provider: 'openai',
    config: {
      apiKey: env.OPENAI_API_KEY,
      model: 'gpt-5',
    },
  },
});

Expected Behaviour

• Setting disableHistory:true will prevent loading of Sqlite 3. Especially important on Lambda runtime

Current Behaviour

• mem0 still tries to load Sqlite3, causing runtime errors on AWS Lambda

[ChenKuanSun]

TL;DR mem0’s factory eagerly imports multiple adapters/providers at module load. Because those imports aren’t tree-shakable, the bundle ends up always pulling in optional deps (e.g., sqlite3) and even forces manual installs. On AWS Lambda this triggers native-binding errors even when disableHistory: true (i.e., when SQLite shouldn’t be used at all). Docs for reference: https://docs.mem0.ai/open-source/node-quickstart#general-configuration

Why this is painful

• The factory loads a “kitchen sink” of adapters up front. Since they’re top-level imports, bundlers can’t shake them off.
• Serverless targets (Lambda, edge) fail on native deps like sqlite3 even if that path won’t be used at runtime. (it takes 2GB, even you bundle as layer)
• It increases maintenance cost for users who only need a minimal setup.

I get that the team may be focused on the hosted platform, but this packaging makes the OSS SDK hard to adopt in production/serverless environments.

Suggested direction (LangChain-style adapters) Refactor to decouple the core from integrations and lazy-import only what the config requires. For example:

• Split packages:

  • @mem0-community/mem0 (core)
  • @mem0-community/openai (LLM adapter)
  • @mem0-community/sqlite3 (history store adapter), etc.

• Make adapters optional peerDependencies and load them conditionally at runtime.

• Publish a tiny Store/LLM interface so the core is generic and tree-shakable ("sideEffects": false).

Developer ergonomics Let users compose their stack explicitly:

import { Memory } from '@mem0-community/mem0';
import { Sqlite3Store } from '@mem0-community/sqlite3';

const historyStore = new Sqlite3Store({ /* ... */ });

const config = {
  historyStore,
  // llm: new OpenAIAdapter({ ... }) from @mem0-community/openai
};

const memory = new Memory(config);

With this approach:

• No sqlite3 is bundled/installed unless the user opts into the SQLite store.
• disableHistory: true truly results in no store code paths or deps being loaded.
• Works cleanly on Lambda and other constrained runtimes.

Happy to contribute a PR/proposal if this direction sounds acceptable.

[ChenKuanSun]

The only reliable fix right now is to fork the repo and strip unused adapters from the factory so they never get imported/bundled.

Steps

1. Fork & clone mem0-ts.
2. Edit mem0-ts/src/oss/src/utils/factory.ts and remove any imports/registrations you don’t need — especially sqlite3 and any SQLite store adapter.
   • Make sure no barrel (index.ts) re-exports those symbols.
3. In the OSS package’s package.json, remove sqlite3 (and other unneeded adapters) from dependencies/peerDependencies.
4. Delete related adapter files (or move them behind truly dynamic imports) so bundlers can’t pull them in.

[auditt98]

@ChenKuanSun Thanks for the workaround, this is driving me crazy.

[satvic-jurin]

Any updates on this issue ? I'm working with Next.js and Mem0 and it's turning out to be a real pain.

[samuelexferri]

Same issue. The hard dependency on sqlite3 breaks the build on Node.js (macOS ARM64, Node 22).

Please fix this. Adapters with native addons like sqlite3 should be optional.

For now, I'm using pnpm patch to remove sqlite3 from package.json and the compiled index.js/mjs instead of forking.