A Ring That Isn’t a Ring: Building a Pacific Evidence Atlas with Metabase

23 July, 2026

The “Ring of Fire” is one of those phrases that is vivid enough to feel self-explanatory—and misleading enough to deserve interrogation.

It suggests a clean circle of fire around the Pacific. In reality, the Pacific margin is a vast, uneven system of plate boundaries, subduction zones, volcanic arcs, fault systems, and island chains. It has no scientific start or end. It is not one phenomenon, one risk category, or one continuous line. It is a popular name for many linked but distinct geological settings.

That distinction became the starting point for Restless Pacific, an interactive atlas of Pacific volcanoes, earthquakes, plate boundaries, and tsunami records. The project is designed less as an alarm map and more as a way to read evidence: in geographic and historical context, with the limits of that evidence kept in view.

The central question was not simply, “How do we put Pacific geology on a website?” It was: how do we make a large, imperfect, multi-source scientific record explorable without turning it into false certainty?

Metabase became a major part of the answer.

The Pacific is a system, not a spectacle

The phrase “Ring of Fire” broadly describes the volcano-rich margins around the Pacific Basin. Much of that activity is associated with tectonic plate boundaries—especially subduction zones, where one plate descends beneath another and can generate earthquakes, magma, and volcanic arcs. But the story is more complicated than a single fiery ring. Some volcanism occurs away from plate boundaries, such as Hawaii’s hotspot chain. Different margins have different tectonic histories, rates of movement, records, and risks. The USGS overview of plate tectonics is a useful place to start.

That complexity matters for public-facing visualization.

A map filled with red dots can make the Pacific appear uniformly dangerous. A dense earthquake layer can look like a hazard forecast. A time series can imply that missing observations mean quiet periods. A tsunami impact chart can flatten enormous differences in historical recordkeeping, exposure, and reporting.

Restless Pacific therefore begins with a simple editorial principle:

Science as a landscape, not an alarm.

The application guides visitors through a narrative journey, an interactive atlas, a historical section, a Data Lab, and a Sourcebook. Each mode serves a different purpose:

• The journey challenges the popular image of the Ring of Fire.
• The atlas provides geographic orientation.
• The history section turns a sprawling geological timescale into readable moments.
• The Data Lab exposes the analytical record.
• The Sourcebook explains sources, methods, and constraints.

That separation is deliberate. Storytelling and analysis should support each other, but they should not be confused for the same thing.

The problem with “just add charts”

The underlying data comes from several different scientific and historical systems:

• Smithsonian Global Volcanism Program data for volcanoes and eruptions.
• USGS earthquake and plate-boundary data.
• NOAA’s historical tsunami record, which includes source events, runups, water heights, fatalities, damage, and other fields where available. NOAA’s NCEI Global Historical Tsunami Database documents both the scope and the different kinds of records it contains.

These are not interchangeable datasets. They differ in grain, time coverage, confidence, update cadence, and what their fields actually mean.

An earthquake record is a seismic observation. A volcano record may represent a named volcanic system with a long, unevenly documented history. A tsunami entry may describe a source event or an observed runup at a particular coastline. Plate boundaries are spatial context; they are not an explanation of every nearby earthquake or eruption.

The technical architecture had to preserve those differences instead of hiding them behind a polished interface. Data is ingested into PostGIS, shaped into read-only analytical views, and surfaced through a Clojure backend. The public application uses Next.js for the narrative experience and interactive mapping, while Metabase turns the analytical views into living dashboards.

This division of labour is what made the visualizations credible. Metabase was not asked to become the entire product. It became the analytical instrument inside a carefully designed public experience.

Metabase as the Data Lab

The Data Lab is the project’s analytical core: four live workspaces, sixteen saved questions, and five read-only analytical views. Rather than presenting one large dashboard with every possible chart, the experience is split into four focused sections.

1. Overview: what is actually in the record?

The overview answers a foundational question that many data visualizations skip: what is present in the analytical store, and how complete is it?

It combines a Pacific observation-density grid map, record counts by dataset, known-value completeness measures, and a temporal-coverage view.

The important wording here is observation density, not hazard intensity. A dense cluster of records can reflect geological activity, but it can also reflect reporting systems, monitoring capacity, historical attention, or the data model itself. The interface states that caveat directly.

This is a small design decision with large consequences. Before visitors compare eruptions, earthquakes, or tsunami impacts, they can first inspect the limits of the record they are about to interpret.

2. Volcanoes and eruptions: making the reviewed volcanic record explorable

The volcano workspace focuses on the reviewed Smithsonian Global Volcanism Program scope: 688 volcanoes across 41 PROF regions.

Its visualizations include a regional comparison of reviewed volcanic records, a volcano-type mix, confirmed eruptions by decade, and a Volcanic Explosivity Index distribution.

The dashboard uses native Metabase filters for region and start year, with historical trends defaulting to 1960. That default is an editorial choice as much as a technical one: it gives visitors a useful modern window without pretending that earlier records are equally complete.

The interface also keeps missing VEI values visible as unknown. Treating unknown values as zero, or quietly excluding them, would produce a cleaner chart and a weaker analysis.

3. Earthquakes and plates: context without causal shortcuts

The seismicity workspace combines recent earthquake observations with plate-boundary context. Visitors can adjust the lookback period and minimum magnitude, then compare recent earthquake-density grids, magnitude-versus-depth scatterplots, daily earthquake activity, and plate-boundary length by boundary type.

This section has a particularly important caveat: nearby plate boundaries provide spatial context, never causal attribution.

It is tempting to draw a line from a boundary to a nearby earthquake or eruption and imply a direct explanation. Real geological relationships are more conditional. Timing, depth, fault geometry, stress state, volcanic plumbing systems, and many other factors matter. The visualization can show patterns worth investigating; it should not claim to settle causality.

4. Tsunamis and impacts: showing consequences without erasing uncertainty

The tsunami workspace brings together historical event density, event frequency, water height, cause, and recorded impact.

It includes a tsunami-event density grid, events by decade and cause, water height compared with recorded deaths, and a table of the highest recorded impacts. Visitors can filter by starting year and cause.

But the central message is not that the dataset is complete. It is that impact totals and water heights are incomplete and observation-dependent.

That is especially important for historical disasters. The absence of a death total is not the same as zero deaths. The absence of a reported water height is not evidence that there was no wave. NOAA’s historical database is extraordinarily valuable precisely because it preserves these records and their fields—but its records remain artifacts of documentation as well as of physical events.

Why Metabase was the right visualization layer

Metabase helped because it solved the analytical problems that would have been expensive and fragile to rebuild from scratch.

It provided:

• Saved, reusable questions.
• Dashboard layouts.
• Native dashboard filters.
• Live queries against the read-only analytical surface.
• A consistent interaction model across datasets.
• A way to update or extend analysis without re-implementing chart primitives in the application.

Just as importantly, it allowed the project to keep the visualization logic close to the analytical model. A chart is not merely a front-end component; it encodes a question, a grouping, a filter, a default window, and a set of assumptions. Storing those questions as managed Metabase resources makes them inspectable and repeatable.

The project provisions those resources idempotently. That means the backend can safely reconcile saved questions and dashboards rather than creating duplicates on every deployment. The system maintains stable resource keys while keeping numeric dashboard IDs internal. The front end depends on the analytical identity of a dashboard, not on an incidental database ID.

Embedding Metabase without giving away the keys

Public analytics requires more than placing an iframe on a page.

Restless Pacific uses Metabase OSS guest embedding. When a visitor approaches a Data Lab section, the application resolves the appropriate stable resource key and requests a short-lived, server-generated token. The backend signs that token; the browser never receives the embedding secret.

Metabase then verifies the signed JWT and loads the published dashboard. Guest dashboards can display live database results without requiring every visitor to have a Metabase account. Metabase’s guest-embedding documentation explains the signed-token model and its trade-offs.

That architecture matters for three reasons:

1. The embedding secret stays on the server.
2. The public application exposes only intentionally published dashboards.
3. The dashboards query a read-only analytics boundary rather than the application’s full database.

Metabase’s guest-embedding model is a strong fit for a public educational project: it supports live dashboards and native filters while avoiding the need to build a complete user-account and analytics-permission system.

There are trade-offs. Guest embedding does not offer the same per-user security, drill-through, query builder, or self-service analytics available with authenticated embedding. But those constraints were useful here. The goal was a guided public evidence lab—not an unrestricted database browser. Metabase’s embedding overview describes where guest embedding fits among its other options.

Designing for performance and attention

Four live dashboards can be heavy, particularly in a stack that also runs PostGIS, data ingestion, a backend service, and the application itself.

The Data Lab addresses this by loading each workspace only as the visitor approaches it. Each dashboard resolves independently, has its own retry and error state, and does not prevent the others from working if one resource fails.

This produces a better experience than loading sixteen charts at once:

• The page becomes useful sooner.
• Memory use is more predictable.
• Visitors encounter one analytical question at a time.
• Failure is contained to the affected section.
• The visual rhythm matches the project’s editorial structure.

Accessibility is part of that design. The four sections have a sticky, keyboard-accessible index. The active section is communicated as the visitor moves through the page. Motion is reduced for people who request reduced motion. Desktop and mobile behavior were both tested, because a visualization system that only works on a large screen is not really a public-facing system.

The visual theme: dark, but not decorative

The application uses a dark Pacific-observatory visual language, and the Metabase embeds use Metabase’s native dark preset to belong to that environment.

That decision was intentionally restrained. Metabase OSS supports light and dark guest themes, while more granular appearance customization is a paid capability. The project uses the native option rather than attempting to disguise the analytics layer with brittle custom styling.

One limitation remains visible: changing the Metabase theme does not recolor external map tiles. The map basemaps remain light because they are a separate visual system with their own provider, availability, and attribution requirements. Leaving that distinction visible is better than forcing visual uniformity at the cost of map legibility or source clarity.

What the project refuses to claim

The most important thing Restless Pacific does is make its limits explicit.

It is not:

• A hazard-alert service.
• An evacuation tool.
• A forecasting system.
• A causal model of eruptions, earthquakes, or tsunamis.
• A claim that historical records are complete.
• A claim that map density equals danger.

It is an educational atlas that invites closer reading.

That restraint appears in the interface copy, the analytical defaults, the Sourcebook, and the chart caveats. The project’s public footer puts it plainly: read the evidence, keep the uncertainty.

For a subject as emotionally charged as the Ring of Fire, that is not an aesthetic preference. It is a responsibility.

The larger lesson

The project demonstrates a useful pattern for public data products.

Do not force one tool to do every job.

Use the application to establish context, guide attention, provide accessibility, and make the experience feel intentional. Use maps for spatial orientation. Use a data platform such as Metabase for dashboards, filters, and analytical repeatability. Keep data access read-only and deliberate. Put uncertainty in the interface, not only in a methods page that nobody reads.

Metabase helped turn a complex PostGIS-backed dataset into something visitors can actively inspect: four focused workspaces, sixteen living questions, native filters, and an analytical surface that stays connected to current data.

The result is not a dashboard pasted into a story. It is a story that knows when to become a dashboard.

Explore Restless Pacific · Open the Metabase Data Lab · Read the Sourcebook