DEV Community: Andrei Sergeev

Troubleshoot MongoDB Replica Sets Easily with Ivory

Andrei Sergeev — Thu, 05 Nov 2026 11:30:00 +0000

Primary, secondaries, heartbeats and lag of the whole replica set in one screen — plus a step-down and a config editor when you need them

MongoDB is one of the easier databases to run highly available. A replica set elects its own primary, fails over by itself, and doesn't need a separate HA tool next to it.

But "it fails over by itself" doesn't mean "you never need to look at it". You still need to know who's primary right now, whether the secondaries keep up, and why one member keeps missing heartbeats. That usually means rs.status() — and a long JSON document to scroll through.

So I taught Ivory to read it for me.

The problems

rs.status() is long. The answer is in there, somewhere in a deeply nested document, one member at a time.
Chained replication hides lag. A secondary syncing from another secondary inherits that secondary's lag, and nothing on the surface tells you why it's slow.
Heartbeat failures depend on who's looking. Member A can't reach member B, but B looks fine from C. You only see it from A's point of view.
Members in odd states. RECOVERING, ROLLBACK, STARTUP — each means something different, and each matters during an incident.
The wrong replica set. Point a node at the wrong address, and you're looking at a perfectly healthy member of a different replica set.

How Ivory solves them

The whole replica set from one member

replSetGetStatus from any member returns the whole replica set, so Ivory can show everything from a single node. Add your cluster by typing its addresses, or give Ivory just one node and let it detect the rest.

The overview shows every member:

Role — PRIMARY is the leader, SECONDARY is a replica. RECOVERING and ROLLBACK are replicas still catching up, STARTUP is starting, an arbiter is running with no data role, and a member that's DOWN is unreachable.
Lag — seconds a member is behind the primary. Ivory warns past 30 seconds.
Tags — only what's worth your attention: the member state when it's anything but primary or secondary, the sync source when a secondary replicates from another secondary, and the heartbeat ping.

That sync source tag is the one I like most. When a secondary is slow because it's chained behind another secondary, the answer is right on the row.

Warnings that say who saw what

Failed heartbeats — and which member saw them. "Heartbeat from mongo1 failed" is a very different story from "mongo2 is down".
MongoDB's own info message for a member, passed through as is, in MongoDB's own words.

And because every node reports its replica set name, a node from another set is flagged right away.

Operations

Failover — asks the current primary to step down (replSetStepDown), so the set elects another one. Great before maintenance on the primary's host.
View and edit the replica set configuration (replSetGetConfig / replSetReconfig). Be careful here: an edit replaces the whole configuration document.

A shell-style console

Each node has a console that feels like the Mongo shell: collection.find(), findOne, insertOne/insertMany, updateOne/updateMany, deleteOne/deleteMany, countDocuments, distinct, aggregate and db.runCommand().

You can browse databases and collections, list running operations and kill one, and use saved queries for server status, replica set status and config, current operations, index usage and the profiler.

The machine behind each node

Give Ivory an SSH key and each node shows its host's CPU, memory, network, processes and any log file. If MongoDB runs in Docker, the Container tab has its logs, inspect, start, stop and restart. A secondary that's slow because of a full disk or a noisy neighbour shows up right there.

Need a new replica set?

Ivory deploys one over plain SSH, from a template. Both templates run the official mongo:7 image as replica set members named after your Ivory cluster, and a post-script on the last node runs rs.initiate once all three are up. Access control is left off.

Mongo (Multi Host) — three nodes mongo1–mongo3, one per machine, on port 27017. Replace the example addresses in the rs.initiate member list with your hosts.
Mongo (Single Host) — all three on one machine on ports 27017–27019. Perfect for a test environment.

After a deploy, Ivory tells you how each node's deploy and initialize steps ended, so if rs.initiate fails, you know exactly where.

Ask your AI agent

Connect Claude, Cursor or Codex to Ivory's built-in MCP server and ask:

"Which node is the MongoDB primary, and is any secondary lagging?"

"Why is mongo3 slow? Check its sync source and its machine."

"Show me the current operations running longer than a minute."

"Step the primary down so I can patch its host — check the secondaries are caught up first."

It works through Ivory, with your permissions. See the MCP docs.

Try it

docker run -p 80:80 --restart always veegres/ivory

Open http://localhost, finish the setup wizard and add your replica set. MongoDB support is in beta: it works end to end, and your feedback will help make it stable.

Let the replica set elect its leaders — you just keep an eye on it. 😉

Useful links:

I Built DTDb — An IMDb for Developer Tools

Andrei Sergeev — Sat, 31 Oct 2026 22:05:09 +0000

We developers have strong opinions about the tools we use every day.

Vim vs. VS Code. PostgreSQL vs. MySQL. Ubuntu vs. Arch. Python vs. Go. And now, with AI coding agents becoming part of everyday development, there are even more tools to compare.

But where can you actually see what developers think about these tools?

There are plenty of comparison articles, sponsored rankings, benchmarks, and opinionated blog posts. But I wanted something a little different.

So I built DTDb — Developer Tools Database.

👉 https://dtdb.dev

What's the idea?

Think of IMDb, but instead of movies, we're ranking developer tools.

The concept is simple:

Developers rate the tools they actually use.
Tools are organized into categories.
Each month, ratings are frozen into a ranking.
You can follow how rankings change over time and see which tools are gaining or losing popularity.

The goal is to create a community-driven picture of the developer tools ecosystem.

What can you find there?

I've started with several categories:

Database engines — PostgreSQL, MySQL, Oracle Database, and others.
Linux distributions — Ubuntu, Debian, Arch Linux, etc.
Programming languages — Python, JavaScript, Java, and more.
AI coding agents — Claude Code, GitHub Copilot, OpenAI Codex, etc.
IDEs and code editors — VS Code, Visual Studio, Notepad++, and others.

This is just the beginning. There are plenty of categories and tools I'd like to add.

Why monthly rankings?

I didn't want DTDb to become just another leaderboard where positions constantly fluctuate.

Freezing ratings into monthly snapshots makes it possible to look back and understand how developer preferences evolve.

For example, it'll be interesting to see how AI coding agents compete over the coming months, or whether developers' preferences for programming languages and databases actually change.

What's next?

There are plenty of things I'd like to improve:

More categories and developer tools.
Better ways to explore historical rankings.
More community participation.
Improvements based on actual user feedback.

But before going too far, I'd love to hear what other developers think.

I'd love your feedback!

A few questions I'm particularly interested in:

Does the IMDb analogy make sense for developer tools?
What categories would you like to see?
Which tools do you think are missing?
Would you actually use something like this to discover or compare developer tools?

This is an independent project, and I'm still figuring out the best direction for it.

Check it out: https://dtdb.dev

Any feedback, criticism, or suggestions are very welcome!

Troubleshoot etcd Clusters Easily with Ivory

Andrei Sergeev — Sat, 31 Oct 2026 12:25:00 +0000

See the leader, the Raft lag and the alarms of every etcd member in one screen — and move the leader with one click

etcd is one of those databases you don't think about. It sits quietly under your Patroni cluster, or under your Kubernetes control plane, and keeps everyone agreeing on who the leader is.

Until it doesn't. When etcd hurts, everything built on top of it hurts too. Patroni can't renew its leader lock, the Postgres primary demotes itself, and suddenly your "database incident" is actually an etcd incident.

I added etcd support to Ivory for exactly this reason. Patroni uses etcd as its coordination store, so if Ivory looks after Patroni, it should look after etcd too.

The problems

Here's what troubleshooting etcd usually looks like for me:

etcdctl needs a lot of flags. Endpoints, certificates, --write-out=table, --cluster… Every time, I have to remember the exact incantation, and type it on the right host.
"Who is the leader?" is a three-endpoint question. etcdctl endpoint status against every member, then reading a wide table to find the one that says true.
Alarms are silent. When etcd runs out of space it raises a NOSPACE alarm and stops accepting writes. Nobody tells you unless you ask with alarm list.
A member from another cluster looks perfectly healthy. If you add the wrong address, it responds, it has a leader, and everything looks fine — it's just not your cluster.
Lag is hidden in Raft indexes. A slow member falls behind on applied entries, and you only notice when requests start failing.

How Ivory solves them

One overview for the whole cluster

Add your etcd cluster to Ivory by typing the node addresses, or just give it one node and let Ivory detect the rest — etcd's member list is the same from whichever node you ask.

The overview shows every member at once:

Role — the member etcd names as leader is the leader, the rest are replicas.
State — whether the member is actually running, observed, not assumed.
Lag — how many Raft entries a member is behind the leader. Ivory warns past 1000 entries.
Tags — the etcd version, the Raft term, and whether a member is a learner.

Each member keeps its etcd name, so what you see in Ivory is exactly what etcd calls it.

Warnings that actually tell you something

Ivory shows two kinds of warnings, labelled separately so you always know who's talking:

What etcd itself reports — alarms like NOSPACE, a lost leader, and a backlog of committed but not yet applied entries big enough for etcd to start refusing requests.
What Ivory notices — a member it can't reach (naming the address it tried, so a routing problem reads differently from a dead member), a node that isn't in the cluster's member list, or a lag past the threshold.

And because every node reports its etcd cluster id, a member from a different cluster is flagged right away instead of rendering as a happy, healthy node.

Move the leader

etcd elects its leader by itself, so there's no failover or restart to manage. But sometimes you want the leader somewhere else — before maintenance on its host, for example. Ivory offers a switchover: pick the member that should lead, and it moves leadership there.

A console without the flags

Every node has an etcdctl-style console: get (with --prefix, --limit, --keys-only), put, del, member list, endpoint status, endpoint health and alarm list. No endpoints, no certificates to type — Ivory already knows them.

There are also saved queries for the things you check most: the member list, endpoint status and health, alarms — and the keys Patroni stores for its clusters. That last one is a lifesaver when you need to know which Postgres node Patroni thinks is the leader.

The machine behind each node

Give Ivory an SSH key, and each node also shows the machine it runs on: CPU, memory, network, the process list and any log file on the host. If etcd runs in Docker, the Container tab shows its logs, lets you inspect, start, stop or restart it. Most etcd problems are disk or network problems, and this is where you see them — no extra SSH session needed.

Need a new etcd cluster?

Ivory can deploy one for you over plain SSH, from a template:

Etcd (Multi Host) — three nodes etcd1–etcd3, one per machine, client port 2379 and peer port 2380. Replace the example addresses in the member list with your hosts.
Etcd (Single Host) — all three on one machine on client ports 2479, 2481 and 2483. Perfect for a test environment.

Both leave authentication off on purpose: that's what lets Ivory's Patroni templates use the cluster as their coordination store right away. Deploy etcd first, then Patroni on top of it, and you have a full high-availability Postgres setup in a few clicks.

Ask your AI agent

Ivory has a built-in MCP server, so you can also connect Claude, Cursor or Codex and simply ask:

"Is my etcd cluster healthy? Any alarms?"

"Which etcd member is the leader, and is any member behind?"

"What does Patroni store in etcd for the prod cluster?"

"Move the etcd leader to etcd2 — check that it's caught up first."

The agent works through Ivory, with exactly the permissions your user has. Details are in the MCP docs.

Try it

docker run -p 80:80 --restart always veegres/ivory

Open http://localhost, go through the setup wizard, and add your etcd cluster. etcd support is currently in beta — it works end to end, but it has had less time in the field than Postgres, so feedback and issues are very welcome.

Keep your Raft afloat, and it will keep everything above it standing. 😉

Useful links:

Stop SSH-ing at 3 A.M. — Just Ask Your Database Cluster What's Wrong

Andrei Sergeev — Mon, 26 Oct 2026 10:02:00 +0000

How to connect Claude, Cursor or Codex to Ivory and let an AI agent troubleshoot PostgreSQL, Redis, MongoDB and more — safely, under your own permissions

It's 3 a.m. Your phone buzzes: replication lag on prod.

You know the drill. Open the laptop. SSH into the first node. patronictl list. Open psql on the leader. Query pg_stat_replication. SSH into the replica. top. df -h. tail the log. Back to the leader. Is something holding a lock? Another query. Copy a PID. Five terminals later, you finally have a picture of what's going on — and you're wide awake for the rest of the night.

Now imagine you type one sentence instead:

"Why is the replica in prod lagging?"

…and an AI agent checks the cluster, reads the lag, looks at the replica's machine, runs the right diagnostic query on the leader and tells you: a long-running transaction on the leader is holding back replay; here's its PID — do you want me to cancel it?

That's what Ivory does now. Let me show you how.

The idea: don't give your AI the keys — give it Ivory

You could give an AI agent SSH access and a database password. Please don't. 🙂

It would have every secret in its context, no idea which cluster is which, and no limits at all — DROP TABLE is just as easy to type as SELECT.

Ivory is an open-source tool to deploy, watch and fix database clusters — PostgreSQL with Patroni, plain PostgreSQL, etcd, Redis, ClickHouse, MongoDB and ZooKeeper. Since v2.1.0 it has a built-in MCP server (Model Context Protocol, the standard way AI agents call tools). So instead of raw access to your infrastructure, the agent gets Ivory:

It already knows your clusters. Names, nodes, roles, which engine, which keeper — no need to explain your topology.
It sees only what you allow. An agent sees only the tools its user has permission for. No permission for a switchover? The switchover tool doesn't even exist for it.
Secrets never pass through it. Passwords and SSH keys stay in Ivory's vault. The agent refers to them by id and never sees them.
Dangerous tools are labelled. Read-only tools are marked read-only, destructive ones are marked destructive, so your client asks you before running them.

"Show me all active queries" — the agent checks six Postgres nodes, finds a long pg_sleep on one replica and offers to cancel or terminate it

Set it up in two minutes

1. Run Ivory (skip this if you already have it):

docker run -p 80:80 --restart always veegres/ivory

2. Generate a token. In Ivory, open Settings → Integrations → MCP Server. Pick how long the token should live — 1 hour, 6 hours, 1 day, 15 days or 30 days — and press generate.

3. Copy the config for your client. The same screen has a ready-made config for Claude Code, Cursor, VS Code, Codex, Antigravity, IntelliJ IDEA and Claude Desktop, with the endpoint and token already filled in. For Claude Code it's one command:

claude mcp add --transport http ivory http://localhost/api/mcp \
  --header "Authorization: Bearer $TOKEN"

That's it. Ask your agent "What clusters do I have in Ivory?" to make sure it works.

10 things to ask your cluster

Here's where it gets fun. These are real prompts that work today, and what the agent does behind the scenes.

1. The morning check

"Check all my clusters and tell me if anything needs attention."

The agent lists every cluster and reads each one's overview: roles, states, lag, pending restarts and warnings. You get one short summary instead of clicking through every cluster. My favourite way to start the day.

2. Why is my replica lagging?

"Why is replica 2 in prod lagging?"

It reads the lag (in the engine's own unit — bytes for Postgres, seconds for Redis and MongoDB, Raft entries for etcd), checks the replica machine's CPU, memory and network, and runs the replication queries on the leader.

3. What is blocking my queries?

"What is blocking queries on the prod leader? Don't kill anything, just explain."

It looks at the active queries and locks and points to the blocker. When you're ready: "Cancel it" — and it uses ivory_query_cancel, or ivory_query_terminate if cancel isn't enough.

4. Is it down, or can I just not reach it?

"Node patroni3 is red. Is it actually down?"

ivory_cluster_check tests every node at once — keeper, machine and database connections — and tells you whether it breaks at the vault, the certificate or the network itself. That's the difference between "the database crashed" and "someone rotated the password".

5. Read the logs for me

"Show me the last errors in the logs of the etcd leader container."

It pulls the last lines of the container log — or any log file on the machine — and summarizes what matters. No ssh, no docker logs, no scrolling.

6. Is the machine OK?

"Is anything else eating CPU on the mongo2 host?"

The agent reads the machine's metrics and process list over SSH, through Ivory. Great for the classic "it's not the database, it's the backup job running on the same box".

7. A planned switchover, done carefully

"I want to switch the leader to node 3. Check that it's healthy and caught up first, then ask me before doing it."

It checks lag and state, explains what will happen, and waits for your go. Ivory even supports scheduling a switchover for later on Patroni: "…and schedule it for 2 a.m."

8. Explain a warning

"Ivory shows a warning on clickhouse2. What does it mean and how do I fix it?"

Ivory has two kinds of warnings: its own (a node that isn't in the cluster, lag past the threshold, an unreachable node) and the ones the engine reports itself (etcd alarms, failed MongoDB heartbeats, stuck ClickHouse replication tasks). The agent knows which is which and explains both.

9. Run the right diagnostic query

"Run the table bloat query on the analytics database and tell me the top 5 tables."

Ivory ships saved diagnostic queries for every engine. The agent can find the right one and run it, so you don't have to remember which pg_stat_* view to join with which.

10. Spin up a test cluster

"Deploy a test Redis cluster on 10.0.0.4 from the single-host template. Use the 'test-ssh' vault for SSH and the 'redis-test' vault for the password."

The agent picks the template and deploys all three nodes — then reports how each node's deploy and initialize steps ended. Credentials are always named by vault, never typed into the chat, so no password ever lands in the agent's context.

Keep it safe: the 3-rule setup

Giving an AI agent power over production deserves a moment of thought. Here's how I set it up:

Rule 1: Give your agent its own user. Create a user in Ivory just for your agent and grant it only view.* permissions. It can diagnose everything and change nothing — the tools that change something simply won't appear in its list. When you need it to act, use a different user with the manage.* permissions you're comfortable with.

Rule 2: Use short-lived tokens. Tokens can't be revoked: Ivory doesn't store them, so a token stays valid until it expires. A 1-hour token for an incident, a 1-day token for a working session. Treat a 30-day token like a password you can't change for a month.

Rule 3: Keep the approval prompts on. Most MCP clients ask before running a tool, and Ivory marks the dangerous ones as destructive. Read before you click "allow" — especially for failover, reinitialize, removing a container and the raw query console.

Some things an agent can never do through Ivory, whatever its permissions: erase data, export backups, or manage vaults, certificates, users and permissions. An agent should never be able to widen its own access.

Tips for better answers

Name the cluster. "Prod" is better than "my database".
Ask it to explain before it acts. "Diagnose, don't fix" is a great default.
Ask for the evidence. "Show me the query you ran and the numbers" keeps the answer honest.
Chain it. "Check all clusters, then dig into the worst one" works surprisingly well.

Bonus: let AI add your favourite database

Ivory's engines are plugins. If your database isn't supported yet, the repository ships a Claude Code agent called keeper-database-plugin that writes a new plugin — both halves, the tests and the UI wiring — following the project's own checklist. Then open a pull request. 🧩

The point

AI won't replace knowing your databases. But it removes the boring part — the five terminals, the copy-pasted PIDs, the "which host was the leader again?" — and leaves you with the decision. And because it works through Ivory, it does that with exactly the permissions you gave it and nothing more.

Next time your phone buzzes at 3 a.m., try asking first. 😉

If you like the idea, give Ivory a ⭐ on GitHub — it really helps.

Useful links:

Troubleshoot Postgres Clusters With Ease Using Ivory

Andrei Sergeev — Mon, 19 Oct 2026 08:09:00 +0000

This is a rewrite of my earlier article, Troubleshoot Postgres clusters easily with Ivory, first published on Medium. Ivory has changed a lot since then, so I've brought the whole story up to date with what it can do today.

When your elephant suddenly takes a nap, you rush to its side to make sure it's doing okay. 🐘

That's how my original article started, when I first introduced Ivory — a tool to get to your elephant's side as fast as possible. Back then it was a small helper for Postgres clusters running Patroni: an overview, a few Patroni buttons, some saved queries and pgcompacttable. Some things in that article are simply not true anymore — Ivory supports Postgres TLS now, it watches plain Postgres replication too, and it now reads the machine behind each node too, so the extra SSH session is gone. So here's the same story, retold the way Ivory looks today.

Why Ivory exists

I'm a developer who supports Postgres clusters with Patroni as the failover system, and managing many of them in different places was exhausting. So I built the tool I wanted to use in my daily work.

These are the problems it set out to solve, and they haven't gone anywhere:

Patroni's CLI and API are hard to remember. patronictl on the right host, the right config file, the right flags — every time.
Troubleshooting Postgres means running specific queries. Which pg_stat_* view was it again, and what do I join it with?
Many clusters means many terminals. Copy-pasting the same commands between hosts and clusters is slow and error-prone.

And a few more I've collected over the years:

"Is it Postgres, or the machine?" Half the incidents are a full disk, a busy CPU or a noisy neighbour — and checking that means yet another SSH session.
Not every cluster runs Patroni. Sometimes it's a plain primary with a couple of standbys, and you still want to see it.
Setting up a test cluster takes too long. Three nodes, etcd, Patroni config, replication… just to try something.

So, how does Ivory solve them?

First: one overview of every cluster

Ivory shows all your clusters in one list, each node coloured by its role — green for the leader, blue for replicas — with warning icons when something's off. Tag your clusters (prod, staging, team-a…) and filter by them.

Adding a cluster takes seconds. Type its nodes, or give Ivory just one node and let it detect the rest: one call to Patroni's /cluster returns every member, with the names Patroni gives them.

Open a cluster and you get the overview of every node:

Role — leader or replica, with synchronous replicas marked
State — running, streaming, stopped, failed…
Lag — bytes behind the leader, with a warning past 50 MiB
Pending restart, scheduled restart or switchover, the timeline, whether the cluster is paused
Tags — everything you set on the member in Patroni's own config

And warnings that actually catch mistakes. A node that's in your config but not in Patroni's answer is flagged. So is a member Patroni reports that you never configured. And because each node reports its Patroni scope, a node that belongs to a different cluster is flagged too — instead of looking like a perfectly healthy member of yours.

Secondly: HA operations in one click

Every Patroni operation is a button:

Operation	When to use
Switchover	Planned leader change — to a replica you pick, or one Patroni picks. Can be scheduled.
Failover	Forced promotion when the leader is gone.
Restart	Restart Postgres on a node. Can be scheduled.
Reinitialise	Wipe a replica and re-clone it from the leader.
Reload	Apply config changes that don't need a restart.
Pause / Resume	Switch Patroni's automatic failover off for maintenance, and back on.

Patroni's dynamic configuration is editable right there too, as a partial patch: change only what you need, and the Pending Restart flag shows you which nodes need a restart to apply it.

No Patroni? Ivory also supports plain Postgres streaming replication — a primary and its standbys, no HA tool in between. It reads roles with pg_is_in_recovery(), replication from pg_stat_replication and pg_stat_wal_receiver, and warns about a standby that isn't streaming or a replication slot that's about to lose its WAL. You can promote a standby (pg_promote()), reload and view the config. Switchover, restart and pause need an HA tool, so for those there's Patroni.

Third: the right query, without remembering it

Every node has a query builder with saved troubleshooting queries, organised by category: Activity (long-running queries, locks, idle connections), Replication (lag, slots, WAL senders and receivers), Bloat, Statistics (autovacuum, cache hit ratio…) and more. Switch between nodes and clusters, and send the same query with one click.

Some nice details:

Labels tell you where a query belongs: Database Sensitive, Master Only, or Replica Recommended for the heavy ones you shouldn't run on the leader.
Prepared statements — put $1, $2 in your SQL, name them, and fill in values at run time.
Your own queries — create custom ones, or edit a system query to fit your setup.
A free console for anything ad hoc, plus a history of your recent queries.
Running queries with cancel and terminate buttons — for that one SELECT that's been running since lunch.
A dashboard with databases, connections, sizes and uptime.

Fourth: pgcompacttable, built in

Ivory still ships pgcompacttable to clean up bloated tables. It compacts tables and rebuilds indexes in small batches with only ROW EXCLUSIVE locks — unlike VACUUM FULL, it's safe on a busy production database.

Ivory runs it as a background job on the leader: pick the database, filter the tables, set a delay between batches, and watch its output live. The bloat estimation queries sit right next to it, so you can measure before and after.

Moreover, Ivory simplifies…

The machine behind each node. Give Ivory an SSH key and every node shows its VM: CPU, memory, network, processes, and any log file streamed live. No agent on your hosts — just SSH.
Containers. If Postgres runs in Docker, see its logs, inspect it, start, stop or restart it.
Deploying a new cluster. Pick a template, fill in the hosts, press Deploy. The shipped templates run Zalando's Spilo (PostgreSQL 18 with Patroni) on three machines — or all three nodes on one machine for a test environment. Need etcd for Patroni? There's a template for that too. Plain Postgres replication templates are included as well.
Password and key management. Passwords and SSH keys live in Ivory's vault, encrypted, and are reused across clusters.
Certificates and TLS. Add certificates once and use them for both Patroni's API and the Postgres connection, including mutual TLS.
Teams. Sign in with Basic, LDAP or OIDC, and give every user exactly the permissions they need — one permission per action.
Your phone. The UI works on mobile, so the 3 a.m. check doesn't need a laptop.
Backups of Ivory itself. Export your clusters, queries and permissions and import them on another instance.

And now, your AI agent can help too 🤖

Ivory has a built-in MCP server. Connect Claude, Cursor, Codex or any MCP client, and ask in plain words:

"Why is replica 2 in prod lagging?"

"What is blocking queries on the leader? Don't kill anything, just explain."

"Switch the leader to patroni3 — check it's caught up first, and ask me before doing it."

The agent works through Ivory, so it sees only the tools your user has permission for, and your passwords never pass through its context. A view-only user gets an agent that can diagnose everything and change nothing. Setup takes two minutes: Settings → Integrations → MCP Server.

Try it

Ivory is one Docker container with no dependencies:

docker run -p 80:80 --restart always veegres/ivory

Open http://localhost, go through the setup wizard, and add your first cluster. Use it as a personal tool on your laptop, or run it on a VM as a shared service for your whole team.

Ivory has also grown beyond Postgres — it now looks after etcd, Redis, ClickHouse, MongoDB and ZooKeeper the same way. But Postgres is where it started, and it's still where it's strongest.

If Ivory saves you some time, give it a ⭐ on GitHub — it helps other people find it and keeps me building it. Feedback, issues and ideas are always welcome.

Treat your elephants with kindness and respect, and they will show you the way 😉 — that was the last line of the original article, and it still is.

Useful links:

Ivory Has a New Home — and the Elephant Grew Wings

Andrei Sergeev — Fri, 16 Oct 2026 06:55:21 +0000

Meet ivory.veegres.com: the website, the docs and a new logo for the open-source tool that deploys, watches and fixes your database clusters

For a long time, Ivory lived in exactly one place: a GitHub repository. If you wanted to learn about it, you opened the README, clicked through a folder of Markdown files and hoped you'd find the right one.

That worked while Ivory was a small Postgres and Patroni helper. It doesn't work anymore. Ivory now manages seven kinds of clusters, deploys them, watches the machines behind them and has an MCP server for AI agents. That deserves a proper home.

So here it is: ivory.veegres.com.

Ivory's UI: every cluster, the health of every node and the machine behind each one, in one screen

Deploy. Watch. Fix. Anywhere.

That's the tagline on top of the page, and it's the shortest description of Ivory I've ever managed to write:

Deploy a cluster from a template over plain SSH.
Watch its health: roles, replication lag, pending restarts and warnings for every node.
Fix it: switchover, failover, restart, reinitialize, run a diagnostic query, read a log.
Anywhere: from your browser, from your phone, or from your AI agent.

What you'll find on the site

Why Ivory, in three sentences

The landing page starts with the three reasons Ivory exists:

Nothing to install. Ivory reaches your machines over plain SSH and talks to each database in its own protocol. No agent beside every node, no Kubernetes, no Ansible, no cloud account — one Docker container and you're done.
One workflow, every engine. PostgreSQL, etcd, Redis, ClickHouse, MongoDB and ZooKeeper look and behave the same: the same health view, the same switchover button, the same console. Learn it once, use it everywhere.
Fix it from anywhere. A UI that works on your phone for the 3 a.m. page, and a built-in MCP server so your AI agent can dig into a cluster with you — under exactly the permissions you have.

Every supported database, at a glance

PostgreSQL with Patroni and plain PostgreSQL replication are stable. etcd, Redis, ClickHouse, MongoDB and ZooKeeper are in beta. And there's one more card: "Yours next?" Every engine in Ivory is a self-contained plugin, and the repository even ships an AI agent that writes a new one for your database by the project's own checklist.

Real documentation, with search

This is the part I'm happiest about. The docs are finally easy to read and easy to search:

Getting started — from docker run to your first cluster
Clusters, Overview and Node — everything the UI does, screen by screen
Deployment — templates, variables and the shipped templates for every engine
A page for every database — what Ivory reads, which operations it offers, how lag is measured and when it warns
MCP server — connecting an agent, permissions and every tool it can call
Comparison tables — operations, lag thresholds and console features for every engine, side by side

A small detail for fellow maintainers: the docs are still the same Markdown files in the repository's .doc folder. The site copies them in at build time, so there's one source of truth, and the docs keep rendering on GitHub exactly as before. The site itself is built with Rspress and served as static files from Cloudflare.

"Just ask your cluster"

The site has a whole section on Ivory being AI-ready, with the kind of questions you can now ask:

"Why is replica 2 lagging?"

"What is blocking my queries?"

"Switch the leader to node 3."

I'll write a separate article on how to make the most of it.

Up and running in a minute

docker run -p 80:80 --restart always veegres/ivory

Run the container, open the setup wizard at http://localhost, choose how people sign in, and add a cluster: type its node addresses, let Ivory detect the rest from one node, or deploy a brand-new one.

Coming soon: a Playground

There's a Playground link in the menu. It's not live yet, but it will be: a real Ivory with a real high-availability cluster behind it, right in your browser — no install at all. Watch the repository on GitHub to know when it opens.

And about that butterfly… 🦋

You may have noticed Ivory has a new logo.

Look closely 😉

It's a butterfly. But look at it again: the wings are a pair of big ears, and the tail curls down like a trunk. The elephant is still there.

Ivory started as a tool for Postgres — and Postgres is an elephant. In my very first article I wrote "When your elephant suddenly takes a nap, you rush to his side." That's still true. But Ivory isn't only about one elephant anymore. It looks after etcd, Redis, ClickHouse, MongoDB and ZooKeeper too, and it can reach them from a browser, a phone or an AI agent.

So the elephant didn't go anywhere. It just grew wings. 🐘➡️🦋

Get involved

Ivory is free, open source under GPL-3.0, and built in my spare time. If you'd like to help:

⭐ Star it on GitHub — one click that helps other people find it.
🧩 Add your database — every engine is a plugin, and there's an AI agent to help you write one.
❤️ Support the project — sponsorship funds new database plugins and features.

Treat your clusters with kindness, and they'll show you the way. 😉

Useful links: