Business Rules In Database Movement
Those who cannot remember the past are condemned to repeat it.
Did you know that there was an entire movement in software development, complete with its own manifesto, thought leaders, and everything, dedicated almost exclusively to putting business logic in SQL databases?
I certainly didn’t. But it did happen in the late 1990s and early 2000s.
Their core philosophy was as follows:
- Data belongs to the organization, not the application. Today, we typically refer to the Bounded Context.
- Rules and constraints should be stored and enforced in the database (or a rules engine), not scattered across individual applications. Today, the Domain Model, of course. But, in essence, just don’t repeat yourself. The database is the source of truth, and no point in having to repeat the same logic across different applications, services, and business reports.
- Rules should be declarative using natural language (not imperative or procedural) to make them easily accessible to a business non-tech audience. Today, we say the Domain Experts, but essentially, the same business people.
- We should be focused on managing business rules, not hardware/software platforms and technology. Today, we would say implementation details, but in essence, it’s the same idea.
And so on. Does this sound familiar?
You can read the full manifesto here (PDF link): https://www.businessrulesgroup.org/brmanifesto/BRManifesto.pdf
An even more fascinating story is why it fizzled out and almost completely disappeared.
According to my research, in the late 90s and early 20s, this movement was hyped, and indeed it was hyped, as confirmed by a stream of conferences, forums, workshops, and thought leaders from that era. Even the research and advisory companies like Gartner promoted the idea under the catchy motto “change the rules, not the code” and labeled it as “hot”.
And then there was a boom of startups building low-code platform tools on this idea, even industry giants like Oracle and IBM tried to incorporate some of these ideas into their own low-code, rule engines. However, the dot-com crash in the early 20s and many startups building BRMS/low-code tools died.
But much more importantly than the dot-com extinction event was a significant cultural shift in the software development world that occurred shortly thereafter:
1) The Agile Movement
Developers preferred flexibility and speed over centralized governance. DBAs and architects pushing data-centric models often lost out to agile, app-centric teams.
In simple terms, development teams from that era had dedicated DBAs, and a dedicated DBA is supposed to implement all those rules in the databases, close to data itself, using declarative SQL:
ALTER TABLE loans ADD CONSTRAINT CHECK NOT (status = 'approved' AND credit_score < 650);
ALTER TABLE users ADD CONSTRAINT UNIQUE(email);
ALTER TABLE users ALTER COLUMN email SET NOT NULL;That was not agile enough, obviously. Those rules should reside in an RDBMS or BRMS (Business Rules Management System), and you will need a specialized person for that.
2) Vendor Lock-In
Obviously, such centralization meant locking into proprietary platforms, which usually meant paying large tech companies a significant amount of money for an extended period, as free and open-source alternatives weren’t yet viable solutions.
3) Perceived Complexity and Technical Limitations
A single, centralized solution is perceived as more complex than a decentralized one, which tends to be repetitive and scattered across various services.
Furthermore, some of the emerging development practices accepted as standard today, such as source control and automated testing, weren’t exactly a priority for this new, centralized RDBMS and BRMS world managed by DBAs.
So what happened then?
The Evolution
The entire software development process started evolving in a different direction, one that is supposed to give more power to the individual programmer and take it away from those DBAs. Arguably, it was successful since dedicated DBAs have become a rare breed these days, at least from my perspective.
Get Vedran Bilopavlović’s stories in your inbox
Join Medium for free to get updates from this writer.
First, in the 2000s, after the dot-com crash, there was an emergence of alternative philosophies.
- First around in 2003 and onward, Eric Evans’ Blue Book and DDD.
- And thereafter, in the 2010s and onward, Robert C. Martin and Clean Architecture.
Both of these philosophies, which are now widely accepted, argue that business rules don’t belong to a centralized data and business rules engines like RDBMS and similar — but rather to the domain model or the architecture core, respectively.
They argue that RDBMS and similar systems are and should be concerned only with storing and retrieving data, and the decision engine should be moved back to the application.
This meant reintroducing business rules back into the application layer, as the industry shifted toward 3-tier architectures with business logic in the middle tier, rather than in the database.
But this also meant that those same rules will inevitably have to be repeated across various applications, services, and reports, which is, of course, suboptimal, to say the least. To address this issue, we saw:
- First, the emergence of Service-Oriented Architecture or SOA in the mid-2000s. The idea was to centralize logic in services where programmers have control.
- And then the emergence of Microservices in the 2010s and onward, with rules scattered across many different specialized services.
Where Are We Today
Today, RDMBS are here to stay, and any component developer (at least the backend developer) should also be a DBA.
After 20+ years, perhaps it is time to revisit some of the arguments that led the industry to reject the Business Rules Movement in the late 90s and early 2000s.
Vendor Lock In:
PostgreSQL is free, open-source, portable, and has a massive ecosystem of support. You’re no longer tied to Oracle licenses just to run stored procedures or triggers.
Switching Scaling Issues
DDD/CA proponents see relying on a database as dangerous: switching DBs or scaling across multiple persistence stores becomes nearly impossible. Scaling relational databases horizontally was hard and proprietary.
But today, there are also numerous distributed and extremely scalable Postgres-compatible free and open source variants as well, such as Citus, Timescale, etc. Scaling isn’t much of a killer anymore. It is challenging, but then again, scaling will always be a challenge.
And with PostgreSQL and its variants, which offer advanced polyglot capabilities covering well over 90 percent of needs, is there still a need to switch? Portability is much less relevant today.
Separation of Concerns
This was a misunderstanding from the beginning; SQL rules are domain semantics, and SQL is not storage code by any means. Postgres doesn’t care where it runs; it enforces rules consistently.
Testing & Tooling
Today, testing DB rules is very straightforward using rollbac-tests, migrations in containers, fixtures, and tools like pgTAP.
It is a weak spot compared to modern app languages with powerful IDEs, refactoring capabilities, and type systems, but it is very much doable and manageable.
The real gap is developer culture: fewer devs are fluent in SQL as a primary modeling language.
Big Picture
The database-centric philosophy is much more defensible in 2025 than it was in 2005. RDMBS and SQL are here to stay, and they are evolving and getting better.
The main “barrier” now is cultural: developers are trained to think in code-first terms, not data-first.
However, we do live in 2025, not in 2005.
