S
Sepio
Back to blog•

The Fallacy of 'Database Agnostic' Design

S
Sepio Engineering
Sepio Team
The Fallacy of 'Database Agnostic' Design

The Myth of the Great Migration

If you were taught software architecture in the era of enterprise Java or early MVC frameworks, you were likely hammered with a specific axiom: “Abstract your database. Make it agnostic. Someday, you might need to swap from PostgreSQL to MySQL.”

This philosophy led to the proliferation of heavy ORMs and Repository patterns designed strictly as lowest-common-denominator wrappers. The goal was to ensure your application code never “knew” it was talking to a specific relational engine.

In modern engineering, this is a fallacy.

The reality is that database migrations across entirely different SQL engines are exceedingly rare. When they do happen, the bottleneck is never the query syntax—it is the data migration, downtime windows, and subtle locking behaviors.

By pretending all databases are just generic storage buckets, you are actively crippling your application.

The Cost of the Lowest Common Denominator

When you restrict yourself to standard SQL-92 features to remain “agnostic,” you leave the most powerful tools in the shed untouched.

Consider PostgreSQL. It is not just a place to store rows; it is an advanced data platform. If you abstract it away, you lose access to:

  • JSONB Types: The ability to index and query schemaless data inside a relational model.
  • PostGIS: The gold standard for geospatial querying.
  • Full Text Search: Native tsvector and tsquery that can often replace the need for dedicated search infrastructure like Elasticsearch early on.
  • Partial Indexes: Indexing only rows where deleted_at IS NULL, drastically saving RAM.
  • Pub/Sub: Using LISTEN and NOTIFY for real-time reactivity without a Redis dependency.

If your ORM or architecture forces you to ignore these features just in case you switch to SQLite in five years, you are paying a massive opportunity cost today.

Embrace the Engine

Modern JavaScript/TypeScript tooling has thankfully started to realize this. Tools like Prisma and Drizzle ORM provide exceptional developer experiences exactly because they don’t hide the database from you.

Drizzle, for example, forces you to import specific dialects (e.g., drizzle-orm/pg-core). Prisma’s schema explicitly defines the provider as postgresql and allows for native database functions. Both tools recognize that leveraging the unique strengths of your specific database engine is a feature, not a bug.

// Drizzle embracing Postgres-specific JSONB and arrays
import { pgTable, text, jsonb, textArray } from 'drizzle-orm/pg-core';

export const events = pgTable('events', {
  id: text('id').primaryKey(),
  tags: textArray('tags'), // Native PG arrays!
  metadata: jsonb('metadata'), // Native PG JSONB!
});

Modeling for Reality

At Sepio, we designed our visual schema builder to respect this reality. We don’t force you into a generic, abstract box. Whether you are generating schemas for Prisma, Drizzle, or raw DBML, our tool allows you to map out complex, database-native types.

Architecture is about making trade-offs. The “Database Agnostic” approach trades immediate, immense performance and productivity gains for a hypothetical database migration that will statistically never happen.

Stop fighting your database. Embrace the engine you chose.