Adapters

BeamWeaver keeps durable runtime dependencies explicit. Applications pass cache, checkpoint, memory, vectorstore, and record-manager adapters into graphs or agents; runtime code depends on behaviours, not Ecto modules.

Implemented local adapters include:

• BeamWeaver.Checkpoint.ETS and BeamWeaver.Checkpoint.Ecto

• BeamWeaver.Cache.ETS and BeamWeaver.Cache.Ecto

• BeamWeaver.Memory.ETS and BeamWeaver.Memory.Ecto

• BeamWeaver.VectorStore.ETS and BeamWeaver.VectorStore.EctoPostgres

• BeamWeaver.Indexing.RecordManager.ETS

• BeamWeaver.Indexing.RecordManager.EctoPostgres

Setup is explicit:

defmodule MyApp.Repo.Migrations.AddBeamWeaverAdapters do
  use Ecto.Migration

  def up do
    BeamWeaver.Migrations.up(adapters: [:checkpoint, :memory, :cache])
  end

  def down do
    BeamWeaver.Migrations.down(adapters: [:cache, :memory, :checkpoint], version: 1)
  end
end

Normal runtime calls never create database tables automatically.

BeamWeaver.Checkpoint.Ecto supports PostgreSQL and SQLite through the same Ecto query/write implementation. The application Repo selects the migration dialect and transaction behavior. SQLite remains optional: applications that choose it add ecto_sqlite3; PostgreSQL users are not forced to install it. Other durable Ecto adapters retain the database support documented by their own modules.

Durable adapters use BeamWeaver.Serialization by default. The default JSON codec is type-tagged and allowlisted; encrypted checkpoint/store payloads can opt in to BeamWeaver.Serialization.Encrypted with an explicit 32-byte AES-256-GCM key:

serialization: [
  codec: BeamWeaver.Serialization.Encrypted,
  encryption_key: :crypto.strong_rand_bytes(32)
]

Keep application database setup in migrations and release tasks. Runtime calls should receive already-configured adapters rather than creating tables or inferring database URLs.