Changelog

Copy Markdown View Source

All notable changes to this project are documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

0.2.0 - 2026-08-25

Fixed

  • A transaction that appends and then reads now sees its own events. The read watermark sits at or below the sequence the appender started from, so its own appends were above it and invisible to it — a decision model, a read model projected in the same transaction, or a test asserting on what it just wrote would come back empty. Appends now publish the sequences they drew in a transaction-local setting that reads let through alongside the watermark.

Changed

  • Requires sourced ~> 0.2, up from ~> 0.1, since the contract suite it compiles into its test build only ships from 0.2.0 onward.

0.1.0 - 2026-08-24

Initial release: a PostgreSQL event store adapter for Sourced, built on Ecto and Postgrex.

Added

  • Sourced.EventStore.Postgres adapter, running on a repo supplied by the host application rather than a pool of its own, so an append can commit alongside the writes it feeds.
  • Sourced.EventStore.Postgres.Migrations — up/0 and down/0 to delegate to from a host migration, creating the sourced_events and sourced_event_tags tables, their indexes and triggers, and the functions the read watermark is computed from. Both tables ship with autovacuum tuned for an append-only workload.
  • Global, monotonic BIGINT sequences from an identity column, so a reader can always resume from the last sequence it saw.
  • A read watermark bounding every read at the highest sequence no in-flight append can still commit beneath, keeping reads gap-free despite rollbacks and out-of-order commits. Appenders publish their starting sequence as a shared advisory lock released on commit, abort, or connection death.
  • SERIALIZABLE appends, with a conditional append's serialization failure translated into a Sourced.EventStore.OptimisticConcurrencyError.
  • Tag queries served by the sourced_event_tags side table, kept in step with the tags column by a trigger.
  • Subscriptions over LISTEN/NOTIFY, so a subscriber hears about appends from every node. A statement-level AFTER INSERT trigger announces the highest sequence an append inserted; each store keeps one listening connection. Subscribing starts with a catch-up read from :from, and the subscription owns its cursor from there, re-querying rather than reading the payload. Delivery is at-most-once and not durable.
  • :name config for running more than one store on the adapter.