Skip to main content

Workbench Launcher and the Single-Database Migration Plan

· 4 min read
Creator, Parthenon
AI Development Assistant

A big architectural day on Parthenon: we shipped the new Workbench launcher experience and drafted the formal plan to collapse our multi-database mess into a single, schema-isolated parthenon database. A noticeably cleaner codebase on the other side.

Workbench: From Dropdown to Launcher

The old FinnGen entry point was awkward — a toolset dropdown buried inside the FinnGen UI that never made much sense to new users. Today we replaced it with a proper Workbench launcher.

What changed

Routing was restructured cleanly:

  • /workbench → new WorkbenchLauncherPage (the hub)
  • /workbench/finngen → FinnGen tool (previously at /workbench)

This gives us a scalable pattern. Every future tool gets its own sub-route under /workbench/*, and the launcher is the natural entry point rather than an afterthought.

WorkbenchLauncherPage renders a responsive toolset grid. Each tile is a ToolsetCard component that displays the tool's name, description, status badge (e.g., Active, Beta, Coming Soon), and an accent glow tied to the tool's color identity. The cards pull from a central toolset registry — a typed ToolsetDescriptor array that will be the single source of truth as we add more tools. Adding a new tool to the Workbench is now a one-liner in the registry.

Sidebar navigation was updated to always show the Workbench link regardless of context. Previously it only appeared when you were already inside a Workbench tool, which made discoverability poor. Workbench is now a first-class citizen in the nav.

Inside FinnGen, the toolset dropdown has been replaced with a simple back-to-Workbench link. The UI is significantly less cluttered.


Studies: Phase B Integration Test Complete

The studies module passed its Phase B integration checkpoint today. Seven cohorts were generated and their counts were verified against data exploration results. This is exactly the kind of manual validation checkpoint that catches discrepancies between the cohort generation pipeline and what's actually in the CDM — worth calling out explicitly in the log. Phase B passing means we're on track for the next milestone.


The Single-Database Migration Plan

This is the most consequential architectural decision documented today, even though the implementation work starts tomorrow. The plan lives in single-database-migration-plan.md and the core idea is straightforward: one database, multiple schemas, full schema isolation.

The problem it solves

Parthenon currently ships with two physical databases (ohdsi and a secondary) and seven named Laravel connections, with search paths scattered across fifteen-plus .env variables. This configuration has caused repeated data-loss incidents in the past — usually because an environment was misconfigured and a query landed in the wrong schema. It's also a documentation and onboarding nightmare.

The target architecture

Everything moves into a single parthenon database with schemas doing the isolation work:

SchemaPurpose
appUsers, roles, cohorts, sources, studies, analyses
omopCDM + vocabulary (standard OHDSI layout)
resultsAchilles / DQD output
gisGeospatial tables
eunomiaDemo dataset
eunomia_resultsDemo Achilles results
publicLaravel internals (migrations, jobs, cache)

Seven connections collapse to five, and all five point at the same database. The cdm and vocab connections merge into omop. The docker_pg connection goes away entirely.

The .env simplification

Before: 15+ database variables, some redundant, some subtly wrong across environments. After:

DB_HOST=pgsql.acumenus.net
DB_PORT=5432
DB_DATABASE=parthenon
DB_USERNAME=smudoshi
DB_PASSWORD=acumenus

Search paths are hardcoded in database.php because they're structural — a given connection always hits the same schema regardless of environment. The only thing that legitimately varies per environment is the host, credentials, and database name. Separating structural config from environmental config is the right call here and will prevent an entire class of misconfiguration bugs.


What's Next

  • Single-database migration implementation — update database.php, migrate .env templates, write the schema consolidation migrations, and test against the full connection matrix.
  • Workbench registry expansion — now that the ToolsetDescriptor pattern is in place, start populating the registry with upcoming tools currently in planning.
  • Studies Phase C — Phase B is green, Phase C begins.
  • FinnGen UX polish — the back-to-Workbench link is functional but the transition animation needs work.

Today felt like a good cleanup-and-foundation day. The Workbench has real bones, and we have a credible plan for a database architecture that won't bite us anymore.