Skip to main content

Framework M Now Proves Cross-Database Portability on Every Merge Request

· 4 min read
Castlecraft Team
Castlecraft Team
Creators of Framework M

Most frameworks ask you to pick one database and hope you never need another. We built Framework M on the opposite assumption: your database is a deployment detail, not an architectural prison.

Today, the same integration suite that validates Framework M's core features also validates them against six relational databases — SQLite, PostgreSQL, MySQL, MariaDB, Oracle, and Microsoft SQL Server — on every merge request and every default-branch commit.

Why This Matters for Enterprise and Government​

In large organizations, database choice is rarely a technical preference. It is a procurement decision, a compliance requirement, or a twenty-year-old operational reality.

Telling a bank, a ministry, or a hospital to "just migrate to PostgreSQL" is not a strategy. It is a resignation letter.

Framework M takes a different path. It lets teams:

  • Keep their existing Oracle or SQL Server estate without rewriting application interfaces.
  • Build the application layer in modern, open-source Python from day one.
  • Migrate the database later if and when the business is ready.

This is particularly relevant for public-sector bodies like India's National Informatics Centre (NIC) and similar agencies worldwide, where digital sovereignty policies prioritize open-source software but existing proprietary databases cannot be ripped out overnight. Framework M makes the transition incremental instead of catastrophic.

What "Same Code, Six Databases" Actually Means​

We do not mean "it compiles on six databases." We mean the same DocType definitions, the same repository calls, the same controllers, and the same business logic run on all six without source changes.

Our shared BaseDatabaseFlowTests class now runs 28 integration tests per database, ensuring absolute feature parity across dialects:

Feature CategoryVerified Behaviors Across All 6 Dialects
Data IntegrityCRUD operations, Child tables & cascade deletes, Unique constraint violations
Query EngineFilter combinations (GTE, LIKE, IN, IS NULL), Link field & fetch-from resolution
Performance & ScalePagination with deterministic tie-breaking, Multi-field ordering, Exists / count optimizations
Lifecycle ManagementOptimistic concurrency, Soft delete behavior

These tests run in CI on every change. If a commit breaks portability, we know before it reaches main.

The Dialect Surprises We Hardened Against​

SQLAlchemy gets you 90% of the way to portability. The last 10% is where databases reveal their personalities. Recent work included resolving these critical behavioral gaps:

  • MSSQL rejects VARCHAR(max) in unique indexes, so unbounded strings now map to VARCHAR(255).
  • MSSQL requires an ORDER BY whenever OFFSET/LIMIT is used, so the repository now automatically applies a deterministic default order.
  • MySQL/MariaDB require explicit lengths on child-table reference columns.
  • MySQL/MariaDB report unique violations as "Duplicate entry" rather than "duplicate key", so our error detection now covers both.
  • Oracle treats empty strings as NULL, a quirk application developers must still respect.

These are not hacks. They are isolated in dialect-specific schema mappers and repository error handling, keeping your application layer completely clean.

A Message to Everyone Trapped by Database Lock-In​

Modern Python application frameworks no longer need to relegate SQL Server and Oracle to second-class status. With an evidence-backed test suite, Framework M proves that enterprise estates can be treated as first-class citizens alongside open-source alternatives.

This message is not only for Microsoft and Oracle. It is for the partners, systems integrators, and DBAs who are asked to make impossible migrations look easy. It is for government agencies and public-sector teams balancing digital sovereignty mandates against decades of operational data. It is for CTOs, architects, and developers who are tired of being told that their existing database is the reason they cannot modernize.

For organizations running SQL Server or Oracle, this is an opportunity: you can adopt cloud-native, async Python business applications without abandoning the data platform you already operate. For open-source advocates, it is a bridge: organizations can move the application layer to open source today and decide on the database layer tomorrow. For everyone in between, it is proof that your database can be a deployment detail instead of a career problem.

What Is Already Documented​

This work ships with two new reference documents:

Cross-database portability is a continuous commitment, not a one-time feature. We will keep expanding the shared test base as the framework evolves.

If you are building business applications and database lock-in keeps you awake at night, Framework M is designed for you.