CONSULTING • SINCE 2004

Data, decoded. Software, delivered.

DATABASE · DATA ARCHITECTURE · SOFTWARE · CRM

Two decades of building data and software systems for businesses that depend on them.

Start a conversation
Explore

The work

When the database
starts to push back

Databases get slower for predictable reasons — a schema decision made years ago, indexes that no longer match the queries, a write pattern the engine wasn't designed for. The fix is rarely buying a bigger machine.

Performance & tuning

Slow queries are usually a symptom of something specific — a missing index, a bad join order, a query plan the optimizer is getting wrong, a write pattern wrecking the cache. Find the real cause, and fix it. The one that surfaces on the dashboard first might not be it.

  • Query plan analysis, statistics tuning, and index design across Oracle, PostgreSQL, and MariaDB
  • AWR/Statspack, pg_stat_statements, performance_schema — tracing the real hot paths, not the suspected ones
  • Connection pooling, vacuum and maintenance scheduling, partition strategy for tables that have outgrown a single segment

Schema design & modeling

The schema you started with rarely survives ten years of business changes intact. Redesign for what you do now — normalize where it helps, denormalize where it has to, and get the constraint and integrity model right so the data stays clean without heroics from the application layer.

  • Normalization and intentional denormalization for read-heavy paths, with grain decisions documented
  • Constraints, triggers, deferrable foreign keys, and check constraints that match real policy
  • Partitioning, sharding, and read-replica strategy for tables that have outgrown a single primary

Migrations & upgrades

Major-version upgrades, cross-platform moves, on-prem to cloud — done with a tested cutover and a real rollback path, not a maintenance window prayer. Rehearse end-to-end before the real one.

  • Oracle ↔ PostgreSQL, on-prem to AWS RDS/Aurora, Azure, or GCP, version-to-version with logical replication
  • Schema and data validation, row-count and checksum diffs, application smoke tests automated against the new instance
  • Phased cutover with read-replica promotion and clean rollback paths if something surfaces post-cutover

When the numbers
need to be right

Operational databases solve one problem; getting that data to a place where analytics, reporting, and ML can use it is a different one. Pipelines, warehouses, and models that hold up under the workload — and under the people asking questions of them.

Modeling for analytics

Operational schemas are designed for transactions, not for answering "how did the business do last quarter." Dimensional models, slowly-changing dimensions, and grain decisions the BI team can actually reason about — not just live with.

  • Kimball-style star schemas, fact and dimension modeling, SCD Type 1/2/3 where each makes sense
  • Conformed dimensions across business processes so two reports don't silently disagree
  • Grain documentation so analysts know what a row represents without having to guess or ask

Pipelines & ELT

Moving data from source systems to the warehouse on a schedule that meets the SLA, with the observability to know when something's wrong before the dashboard turns red. Idempotent, retryable, testable — not held together by cron and hope.

  • CDC-based ingestion from operational databases (Postgres logical replication, Debezium, AWS DMS)
  • dbt-based transformations with tests, documentation, and CI; or Airflow / Dagster orchestration for non-SQL work
  • Snowflake, Redshift, BigQuery, Postgres — load patterns and sizing matched to the actual workload

Data quality & governance

Wrong numbers reach the executive deck because nobody caught them on the way in. Build the checks that catch them — at ingestion, at transformation, and at the report layer — so the team trusts the dashboards instead of working around them.

  • Source-system contracts, schema drift detection, row-count and checksum invariants between hops
  • Lineage tracking so when a number looks wrong, someone can trace it back to source without grepping
  • Ownership and SLA documentation per table — who owns it, who can change it, how fresh it should be

When the code
has to outlast the project

Custom software written so the next person can pick it up — well-tested, well-documented, built on boring technology that doesn't ship a new major version every six months. The engagement ends; the system keeps running.

Backend systems & APIs

Java and C++ services, REST and gRPC APIs, message-driven pipelines, async workers. Designed for the workload, instrumented for the operations team, built with dependencies you'll still find docs for in five years.

  • Java (Spring, Jakarta EE, plain JVM), modern C++ (C++17/20), Python where it fits
  • REST and gRPC APIs with OpenAPI/proto contracts, generated clients, versioning that doesn't break consumers
  • Async work over Kafka, RabbitMQ, or SQS — with the retry, DLQ, and idempotency design that makes them safe at scale

Integrations & legacy work

Connecting systems that weren't designed to talk to each other, and keeping older codebases running well past the date they were "supposed" to be replaced. The boring work is often the work that actually matters.

  • ETL between legacy databases and modern services, file-based interchange, SOAP-to-REST adapters
  • Maintaining and extending C++ codebases older than most of the team, without breaking the parts that work
  • Migration strategies from monoliths or older stacks, done incrementally — not the 18-month rewrite that gets cancelled at month 14

Testing, observability & handover

The deliverable isn't just the running code — it's the running code plus the tests, the runbooks, the metrics, and the documentation that let someone else operate it. Half the value of consulting is what you leave behind.

  • Unit, integration, and contract tests with a CI pipeline that runs them on every change
  • Structured logging, metrics, and distributed traces — enough that the team can debug production without paging the consultant
  • Architecture decision records, runbooks for common ops scenarios, README walkthroughs that get someone productive in an afternoon

When the platform
doesn't quite fit

Salesforce and HubSpot are great starting points. The custom work is what makes them yours — modeling your actual business, wiring them into the rest of the stack, and untangling them when it's time to move on.

Custom data models

Custom objects, relationships, validation, record types, and picklists designed around how your business actually operates — not how the platform's defaults assume you should. Built so a new admin three years from now can still read the schema without flinching.

  • Salesforce custom objects, master-detail and lookup relationships, junction tables for many-to-many
  • HubSpot custom objects, custom properties, association labels for B2B account hierarchies
  • Validation rules, duplicate rules, sharing models, and field-level security that match real policy

Integrations that hold up

Your CRM rarely lives alone. Bidirectional sync with ERPs, billing, marketing automation, support tools, and the data warehouse — built on idempotent operations, retry queues, and structured logging so you hear about failures from monitoring, not from sales.

  • REST/SOAP APIs, Bulk API, Composite API, Platform Events, Change Data Capture (Salesforce)
  • Webhooks, custom-coded workflow actions, Operations Hub sync, private apps (HubSpot)
  • Bidirectional sync into NetSuite, Marketo, and other ERP, accounting, and marketing automation platforms
  • Pipelines into Snowflake, Redshift, BigQuery, or Postgres for reporting that the BI team can trust

Migrations & consolidations

HubSpot to Salesforce, the other direction, or off a legacy CRM entirely. Schema mapping, deduplication, historical preservation, and a phased cutover plan that doesn't lose deals in the seam between the old system and the new.

  • Field-by-field mapping with documented decisions for the cases where one platform's model doesn't translate cleanly
  • Data quality work up front — dedup, normalization, ownership reassignment — so you migrate clean data, not a mess
  • Cutover sequencing with rollback paths, so the team isn't locked out if something surfaces at go-live

How it works

Senior, hands-on

You work directly with the principal, who learns the business, recommends the process, writes the code, and stays accountable for the outcome.

Pragmatic over trendy

The right tool is usually the boring one. Pick what fits the problem, the team, and the operational reality — not the resume.

Built to outlast the engagement

Documentation, tests, and clean handover are part of the deliverable. The engagement ends; the system keeps running.

Two decades
of specialist work

Triview has been delivering specialist consulting in database management, data architecture, and custom software development since 2004.

As a focused one-person practice, every engagement gets direct senior attention — from the first scoping call through to handover. No bench, no junior shadows, no account managers.

The work spans Oracle and PostgreSQL tuning, warehouse and pipeline design, Java and C++ systems, and full-stack Salesforce and HubSpot delivery. The thread connecting them: building things that hold up under real load, real edge cases, and real time.

CORE STACK
  • Oracle · PostgreSQL · MariaDB · DynamoDB
  • Snowflake · Redshift · BigQuery
  • AWS · Azure · GCP
  • Java · C++ · Apex · Python
  • Salesforce · HubSpot

Let's talk

Have a database that's slowing down, a data model that needs rethinking, or a project that needs senior delivery? Send a note — let's set up a call.