Claude, Start My Database - EventSourcingDB
Skip to content
Initializing search
Getting Started
Fundamentals
Deployment and Operations
Reference
Client SDKs
Extensions
MCP Server
Best Practices
Implementation and Development
Data Management and Performance
Operations, Compliance and Infrastructure
Common Issues
Blog
Categories
Privacy Policy
Legal Notice
Claude, Start My Database¶
When we released the Claude Code Plugin for EventSourcingDB at Easter, we proudly listed everything it did not need: no SDK, no MCP configuration, not even a Docker container. Claude had learned to speak EventSourcingDB fluently. But there was a quiet assumption baked into every conversation – that somewhere, someone had already started a database for Claude to talk to.
Version 1.1.0 of the plugin removes that assumption. Claude can now start a local EventSourcingDB on its own , and it has picked up a few habits that make longer sessions noticeably smoother: consistent event sources, uniform event type prefixes, and a deeper understanding of the CloudEvents format. In this post, we walk through what is new – along a session that begins with an empty terminal and ends with a queryable event store.
One Sentence to a Running Instance¶
The headline feature of 1.1.0 is the new /esdb:start-server Skill. You type: "Spin up a throwaway EventSourcingDB for me." That single sentence replaces a Docker command you would otherwise have to remember, or at least look up:
docker run -d --rm --name eventsourcingdb-dev -p 3000:3000 \<br>thenativeweb/eventsourcingdb:latest run \<br>--api-token=secret \<br>--data-directory-temporary \<br>--http-enabled \<br>--https-enabled=false \<br>--with-ui
We wrote about this setup in Local Development Setup: EventSourcingDB in 5 Minutes – it is not complicated, but it is exactly the kind of incantation you forget between projects. Now Claude remembers it for you. The instance it starts runs in development mode : data lives in a temporary directory, the server speaks plain HTTP instead of HTTPS, the built-in management UI is enabled, and the API token is simply secret. A few seconds later, Claude reports back with the API base URL, the address of the UI, the token, and a reminder that everything is ephemeral.
The Skill does more than fire off a command. Before starting anything, it checks that Docker is actually running , looks for an existing development instance, and verifies that the port is free. If an instance is already up, Claude tells you so and hands you the connection details instead of starting a second one. If another process occupies port 3000, Claude asks you which port to use instead. And if you want a specific image version or a different token, you just say so – the defaults are defaults, not dogma.
It is worth pausing on two of those defaults, because they shape what the instance is good for. The temporary data directory means the database starts empty every single time – and that is a feature, not a limitation. Demos begin from a clean slate, test runs cannot contaminate each other, and you never have to wonder what leftover state from last Tuesday is skewing your experiment. And the management UI , served on the same port as the API, gives you a second pair of eyes on the session: while you talk to Claude in the terminal, you can watch subjects and events appear in the browser, or try an EventQL query interactively. If you have not seen the UI yet, Using the Management UI gives you the tour.
One thing the Skill is deliberately strict about: this setup is for development only. Temporary storage and plain HTTP are wonderful for experiments and exactly wrong for production. When you are ready to deploy for real, Running EventSourcingDB covers the proper way.
A Session from Start to Finish¶
To see how the pieces fit together, let us play through a complete session. You open Claude Code in an empty directory, with nothing running.
Starting the database. You type: "Start a local EventSourcingDB for me to experiment with." Claude runs the preflight checks, starts the container, pings the instance to confirm it is healthy, and suggests exporting the connection settings so all other Skills pick them up automatically:
export ESDB_URL="http://localhost:3000"<br>export ESDB_API_TOKEN="secret"
Writing events. You continue: "Acquire a book called '2001 – A Space Odyssey' by Arthur C. Clarke, and register a reader named Alice." Claude asks you once for your event source and type prefix – more on that in a moment – then writes the events: a book-acquired event for /books/42 and a reader-registered event for /readers/1.
Reading the history. "What happened to /books/42 so far?" Claude reads the event stream for the subject and presents it: one acquisition event, with its timestamp, ID, and payload.
Asking questions. "How many books does the library have?" Claude translates the question into an EventQL query, runs it, and answers. You never left natural language, and you never...